Announcement

Collapse
No announcement yet.

INPUTBOX$ Problem???

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • INPUTBOX$ Problem???

    What am I doing wrong?! This code is simple enough, but doesn't work!! It resets X & Y to zero. I'm missing something very basic, I think. But I can't figure out what... Any comments are appreciated. Thanks!


    #DIM ALL
    #COMPILE EXE
    %USEMACROS = 1
    #INCLUDE "Win32API.inc"
    DEFEXT A-Z


    FUNCTION PBMAIN()
    LOCAL A$
    LOCAL X, Y, Z AS EXT
    A$ = INPUTBOX$("Enter value","INPUTBOX$ Test Program","1.23") : X = VAL(A$)
    MSGBOX("A$="+A$+" val(A$)="+STR$(VAL(A$))+" X="+STR$(X))
    A$ = INPUTBOX$("Enter value","INPUTBOX$ Test Program","4.56") : Y = VAL(A$)
    MSGBOX("X ="+STR$(X)+" A$="+A$+" val(A$)="+STR$(VAL(A$))+" Y="+STR$(Y))
    MSGBOX("X="+STR$(X)+" Y="+STR$(Y) + " X+Y="+STR$(X+Y))
    Z = X+Y
    MSGBOX("Z ="+STR$(Z))
    END FUNCTION 'PBMAIN()

  • #2
    Change your LOCAL X, Y, Z AS EXT, to STATIC X, Y, Z AS EXT. Then they'll maintain value when you do the INPUTBOX$.

    Comment


    • #3
      No, that's a bug in the compiler. It is losing the value of "X" when X is LOCAL.

      This should not happen; LOCAL variables are supposed to retain their values throughout the life of the procedure in which they are defined and used.

      However, that bug may or may not be in the INPUTBOX$ function. Just send the whole source code in to [email protected] with a subject "bug report" and include compiler name and version (I used PB/Windows 9.0.1)

      Changing the variables to STATIC is only a workaround... it is NOT a requirement if the compiler is working as designed.

      MCM
      Michael Mattias
      Tal Systems (retired)
      Port Washington WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        The variables are being allocated as REGISTER variables and the FP registers are not being preserved when INPUTBOX$ is called.
        It's a bug .. and has been since PBWin7 at least (that's my earliest PBWin compiler).
        A short term fix would be to use #REGISTER NONE for the SUB that uses INPUTBOX$.
        I'm sure it'll be fixed soon.

        Paul.

        Comment


        • #5
          It's a bug .. and has been since PBWin7 at least ....
          ...
          I'm sure it'll be fixed soon
          I guess 'soon' must be relative.

          Ok, in fairness... this may never have been reported before. It happens.

          I once got a bug report for a piece of software I had made available for download for free.... NINE YEARS earlier.

          (Took me all of five minutes to fix).
          Michael Mattias
          Tal Systems (retired)
          Port Washington WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            Man, that did seem a bit odd, as I thought it should be preserved. Just wrote it off as something odd about the INPUTBOX$ function.

            Comment


            • #7
              > Just wrote it off as something odd about the INPUTBOX$ function.

              Don't do that.

              If something is not working as documented, report it.

              Taking the time to do that is a pretty small price to pay in exchange for the kind of support you get here free, isn't it?

              You can repay those favors by reporting bugs so all the rest of us can benefit from the fixes.
              Michael Mattias
              Tal Systems (retired)
              Port Washington WI USA
              [email protected]
              http://www.talsystems.com

              Comment


              • #8
                BTW, I think Mr. CEM Ventures Ltd, you will soon be asked to register here with a real name.

                Frankly I don't know how you have been able to survive under that name to make four (4) posts, they usually catch thiskind of thing pretty quickly.

                MCM
                Michael Mattias
                Tal Systems (retired)
                Port Washington WI USA
                [email protected]
                http://www.talsystems.com

                Comment


                • #9
                  Just in case, I DID report it.
                  Michael Mattias
                  Tal Systems (retired)
                  Port Washington WI USA
                  [email protected]
                  http://www.talsystems.com

                  Comment


                  • #10
                    Is this not that re-entrant thing with the MSGBOX again?
                    Rod
                    In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.

                    Comment


                    • #11
                      >Is this not that re-entrant thing with the MSGBOX again

                      Who cares? It's a bug!! "Something" in that procedure is resetting the value of "X" to zero when it shouldn't!

                      So report it to the experts and let them deal with it!

                      (But to answer your question: No).
                      Michael Mattias
                      Tal Systems (retired)
                      Port Washington WI USA
                      [email protected]
                      http://www.talsystems.com

                      Comment


                      • #12
                        To Bug or Not To Bug

                        I am reluctant to say its a "BUG" because 99.8% of the the time the "BUG" is an error in my code.

                        However it should not be written off if you can not find a cause, and truely feel it could be a bug. and then submit it to PB for verification.

                        My 3 minute pass on your code can show that I believe the problem only occurs using the EXTENDED data-type (If you change to LONG (whole Numbers) or CURRENCY (Decimal Points) using your values, the correct results occur)

                        #DIM ALL
                        #COMPILE EXE
                        %USEMACROS = 1
                        #INCLUDE "Win32API.inc"
                        DEFEXT A-Z
                        Code:
                        FUNCTION PBMAIN()
                             LOCAL A$
                             LOCAL X, Y, Z AS CURRENCY 'long 'EXT
                             A$ = INPUTBOX$("Enter value","INPUTBOX$ Test Program","1.23") : X = VAL(A$)
                        MSGBOX("A$="+A$+" val(A$)="+STR$(VAL(A$))+" X="+STR$(X))
                             A$ = INPUTBOX$("Enter value","INPUTBOX$ Test Program","4.56") : Y = VAL(A$)
                        MSGBOX("X ="+STR$(X)+" A$="+A$+" val(A$)="+STR$(VAL(A$))+" Y="+STR$(Y))
                        MSGBOX("X="+STR$(X)+" Y="+STR$(Y) + " X+Y="+STR$(X+Y))
                             Z = X+Y
                        MSGBOX("Z ="+STR$(Z))
                        SameFunction
                        END FUNCTION 'PBMAIN()
                        
                        FUNCTION SameFunction()
                             LOCAL A$
                             LOCAL X, Y, Z AS EXT
                             A$ = INPUTBOX$("Enter value","INPUTBOX$ Test Program","1.23")
                             X = VAL(A$)
                        MSGBOX("A$=" + A$ + SPACE$(5) + "val(A$)=" + STR$(VAL(A$)) + SPACE$(5) + " X="+STR$(X))
                             A$ = INPUTBOX$("Enter value","INPUTBOX$ Test Program","4.56")
                             Y = VAL(A$)
                        MSGBOX("X =" + SPACE$(5) + STR$(X) + SPACE$(5) + " A$=" + A$ + SPACE$(5) + " val(A$)=" + STR$(VAL(A$)) + SPACE$(5) + " Y="+STR$(Y))
                        MSGBOX("X=" + SPACE$(5) + STR$(X) + SPACE$(5) + " Y=" +STR$(Y) + " X+Y=" + SPACE$(5) + STR$(X+Y))
                             Z = X+Y
                        MSGBOX("Z ="+STR$(Z))
                        END FUNCTION
                        In the above "SameFunction" was just my attempt to make the MsgBoxes a little bit more readable

                        Engineer's Motto: If it aint broke take it apart and fix it

                        "If at 1st you don't succeed... call it version 1.0"

                        "Half of Programming is coding"....."The other 90% is DEBUGGING"

                        "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                        Comment


                        • #13
                          >show that I believe the problem only occurs using the EXTENDED data-type

                          Is that a DOCUMENTED exception to the rule that LOCAL variables retain their value until assigned a new value or go out of scope? (Hint: the answer starts with "N"). then it's a bug.

                          BTW...
                          Code:
                          MSGBOX("X=" + SPACE$(5) + STR$(X) + SPACE$(5) + " Y=" +STR$(Y) _
                                       + " X+Y=" + SPACE$(5) + STR$(X+Y))
                          The USING$ function can make this code a lot easier to both write and read:
                          Code:
                           S = USING$ ("X=     #     Y=#    X_+Y=#", X, Y, X+Y)
                           MSGBOX S
                          Michael Mattias
                          Tal Systems (retired)
                          Port Washington WI USA
                          [email protected]
                          http://www.talsystems.com

                          Comment


                          • #14
                            See Michael, I told you you make a good conscience. I also have a *lot* of places where that little code change will improve things greatly. Maybe you get to keep your day job too.

                            Comment


                            • #15
                              Hi Michael,

                              Thank you. I have logged this with R&D.

                              Sincerely,
                              Jeff Daniels
                              PowerBASIC Staff

                              Michael Mattias wrote:
                              > 6/21/09
                              >
                              > In case Mr "CEM Ventures Ltd" does not report it, I've attached code
                              > for PB 9.0.1 which shows LOCAL variables not retaining value
                              > throughout their scope.
                              >
                              > More detailed discussion at:
                              > http://www.powerbasic.com/support/pb...ad.php?t=40790
                              >
                              I happen to believe the 'thank you' is sincere.

                              Just ask yourself... would you prefer your users to report any bugs they find in YOUR applications when they find them? Would you rather wait to field that question at 2:00 AM because production is down?

                              While you are at it, when your users report bugs, would you like them to be able to provide the exact failing input so that you can replicate the problem? Or maybe try to remember what happened three days ago?

                              And while *I* am at it, considering there is no 'annual maintenance' fee for access to PB's support, is reporting bugs on a timely basis all that much to ask?

                              MCM
                              Michael Mattias
                              Tal Systems (retired)
                              Port Washington WI USA
                              [email protected]
                              http://www.talsystems.com

                              Comment


                              • #16
                                Personally, I'd never report a bug without some discussion and confirmation here. After a few people duplicate the behavior, then it makes sense to put in a proper report. About 99% of the time the bugs are in the code, not the compiler, and I'd rather PB resources were working on neat new stuff, not troubleshooting my bad code.

                                Comment


                                • #17
                                  >Personally, I'd never report a bug without some discussion and confirmation here

                                  That is a reasonable approach if you are not sure... provided you 'remember' to report it after confirmation.

                                  But even when you ARE sure, you can still make a mistake. I've sent in two 'bug' reports which were not bugs (Give me a break, it's been over a period of nineteen years)

                                  Yeah, I felt a little embarrassed when one turned out to be a spurious underscore which converted an IF..END IF block into a single line IF and the compiler kept giving me a can't compile because an END SELECT or LOOP was expected (you know how those "incomplete loop structure" messages work when you have deeply-nested multiple structures), and one was where I missed a documented limitation because it was buried somewhere on the help page.

                                  But I'm glad I've bothered to report these... they are almost always fixed by the next release (except doc errors, which don't seem to be on ANYONE's front burner, ever.)

                                  (I've often suggested "help file only" updates to deal with unclear, incomplete or erroneous documentation, but that idea does not seem to have caught fire in Florida).
                                  Michael Mattias
                                  Tal Systems (retired)
                                  Port Washington WI USA
                                  [email protected]
                                  http://www.talsystems.com

                                  Comment


                                  • #18
                                    I'm sure it's been suggested before, but it would be really neat to be able to edit my help file to add notes on things I've learned here, or reminders about various potholes I've unwittingly driven into.

                                    Comment


                                    • #19
                                      >I'm sure it's been suggested before,

                                      It has.

                                      But keep sending those new feature suggestions to [email protected] for it is said the more who ask the more likely are all to receive.
                                      Michael Mattias
                                      Tal Systems (retired)
                                      Port Washington WI USA
                                      [email protected]
                                      http://www.talsystems.com

                                      Comment


                                      • #20
                                        >show that I believe the problem only occurs using the EXTENDED data-type

                                        Is that a DOCUMENTED exception to the rule that LOCAL variables retain their value until assigned a new value or go out of scope? (Hint: the answer starts with "N"). then it's a bug.
                                        MCM... I dooooo believe the complete comment was .....
                                        My 3 minute pass on your code can show that I believe the problem only occurs using the EXTENDED data-type (If you change to LONG (whole Numbers) or CURRENCY (Decimal Points) using your values, the correct results occur)
                                        Aka....3 minute pass...and SHOW not PROVE!!!
                                        I did not research if there was a documented exception, nor did I spend more time trying to figure out why EXT was the only tested data type that seemed to be affected.

                                        The USING$ function can make this code a lot easier to both write and read:
                                        I have never tried, but might be useful (as useful as my normally not using macro's until I found 1 reason to use a macro instead of a function).

                                        would you like them to be able to provide the exact failing input so that you can replicate the problem? Or maybe try to remember what happened three days ago?
                                        I run into this all the time, and when I ask "What did it do?" or "What were you doing at the time" I get "Ummm...uhhhhh...I think I did such or such, or I think the error was something like" for a response, just minutes after it happened.

                                        Personally, I'd never report a bug without some discussion and confirmation here. After a few people duplicate the behavior, then it makes sense to put in a proper report. About 99% of the time the bugs are in the code, not the compiler, and I'd rather PB resources were working on neat new stuff, not troubleshooting my bad code.
                                        I am of the same mind as Conrad. I would rather post, and have someone point out a I made. Or someone that I know is wayyyyy more knowledged in particular areas (people like Pierre, Gosta, Paul, (and Yes even MCM from time to time), amongst the many, Many, MANY others that have offered some hint, or post or even glimmer that struck me as "What IF I tried this???")
                                        This way I am not not bugging PB to chase ghosts that never existed, and it was truly my fault.

                                        (I've often suggested "help file only" updates to deal with unclear, incomplete or erroneous documentation, but that idea does not seem to have caught fire in Florida).
                                        Although the RAREtimes I have seen a mis-documentation, I did see one in 9.0 that I sent to PB about a minor detail in ArrayAttr while beta-testing 9.01, it was fixed when 9.01 came out. So I would not say that documentation is not on the front burner


                                        The best part I love is when I do submit to PB for support, not only are they timely, they are WELLLLLL ABOVE what I would consider timely (especially when I am in a situation, that I could swear it had something to do with the compiler, when it really had something to do with my code)

                                        Which is why I hold off and let others confirm or deny that a "Bug" may or may not exist before I submit.
                                        Engineer's Motto: If it aint broke take it apart and fix it

                                        "If at 1st you don't succeed... call it version 1.0"

                                        "Half of Programming is coding"....."The other 90% is DEBUGGING"

                                        "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                                        Comment

                                        Working...
                                        X