Announcement

**Conrad Hoffman** · 21 Jun 2009, 09:32 AM

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$.

**Michael Mattias** · 21 Jun 2009, 09:42 AM

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

**Paul Dixon** · 21 Jun 2009, 09:49 AM

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.

**Michael Mattias** · 21 Jun 2009, 09:54 AM

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).

**Conrad Hoffman** · 21 Jun 2009, 09:55 AM

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.

**Michael Mattias** · 21 Jun 2009, 10:02 AM

> 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** · 21 Jun 2009, 10:07 AM

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** · 21 Jun 2009, 10:09 AM

Just in case, I DID report it.

**Rodney Hicks** · 21 Jun 2009, 10:45 AM

Is this not that re-entrant thing with the MSGBOX again?

**Michael Mattias** · 21 Jun 2009, 11:40 AM

>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).

**Cliff Nichols** · 21 Jun 2009, 04:45 PM

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

**Michael Mattias** · 22 Jun 2009, 07:57 AM

>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

**Conrad Hoffman** · 22 Jun 2009, 08:31 AM

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.

**Michael Mattias** · 22 Jun 2009, 08:58 AM

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

**Conrad Hoffman** · 22 Jun 2009, 09:31 AM

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.

**Michael Mattias** · 22 Jun 2009, 10:14 AM

>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).

**Conrad Hoffman** · 22 Jun 2009, 12:07 PM

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.

**Michael Mattias** · 22 Jun 2009, 12:16 PM

>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.

**Cliff Nichols** · 22 Jun 2009, 05:36 PM

>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.

Announcement

INPUTBOX$ Problem???

INPUTBOX$ Problem???

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment