numeric overflow

[foxmuldr]

I have a FPW 2.6 screen that uses a numeric input memory variable (m.acct) with a picture clause '999 9999 999' for an input field.

We've taken the SPR and compiled it in VFP9 and it works fine, except that when the user types in all 10 digits it gives a brief wait window that says "numeric overflow" and then continues on properly without data corruption or issue.

I've tried increasing the picture clause to '9999 9999 999', removing the spaces '9999999999' and removing it completely. Nothing changes it. It always gives that message.

I've discovered that it has to do with (2^31)-1, which is the maximum value to store for 31 bits (0x7fffffff). If it's a value that size or smaller, no message. If you get to anything of 32-bits or larger (0x80000000) it causes the error. This happens only on memory variables.

If you input a table field, it works fine.

Does anybody know why this is? Or how to disable the wait window "numeric overflow" message?

Thanks!

Best regards,
Rick C. Hodgin

 

[Dan Freeman]

If you want to change history, please delete the entire thread. Don't put words in my mouth. I cannot imagine a time when I would thank you for this assistance you have doled out.

Note that Olaf does not have the ability to change posts or delete threads.

You should probably thank the TekTips overlords for ending your self-destructive account. I doubt it would be getting much help anyway. When you develop a reputation of being rude people will stop responding.

 

[foxmuldr2]

Okay.

Best regards,
Rick C. Hodgin

 

[foxmuldr2]

I do want to go on record saying one thing for anyone reading this thread and coming across comments made above:

The suggestion above about converting input fields to character, and then back to numeric, is not a good idea. Why? FPW 2.6 applications have likely been in use for many years, and if the app is of any size or scale it likely has multiple screens. In addition, it very easily could've been coded several different ways by several different developers over the years. So the idea of going in and converting every numeric value to a string before the READ, and then back to a numeric value afterward, when it's not known on which when or valid event, or in which called PRG or secondary SPR it might be referenced before the conversion back to numeric, it's truly so far away from a reasonable solution as to be that which I called it formerly (and was kicked off the board for). To put it politely, it's a bad idea. Even an unworkable one.

My ultimate solution was to analyze programmatically all the @ GET commands, and then programmatically insert this test before the READ command for every variable encountered:

IF TYPE("m.variable") = "N"
m.variable = m.variable + (9999999999 - 9999999999)
ENDIF

This solution required no changes whatsoever to the screen, and always worked in every case because every variable that was numeric prior to being issued the READ was converted to the form that would not give the numeric overflow message, being part then of a large computation beyond the value of (2^31)-1.

In short, the idea of converting every numeric input field to a character, and then back again, on code that's existed since FPW 2.6 ... it is not a good suggestion and I advise as strongly as possible against it.

Best regards,
Rick C. Hodgin

 

[Koen Piller]

Hio Foxmuldr2

Your quote
It's a legacy application. We are moving it from FPW 2.6 to VFP9 to get it working. So far, only minor issues. It will be re-written at some point to use classes, but for now it will just be re-compiled.
unquote

makes everything a lot clearer. Moving FFW2.6 to VFP9 and not taking the time to rewrite into a proper VFP9 appl;ication. Sure you will get a lot of odd things to solve. Good luck.

Jockey(2)

 

[foxmuldr2]

Jockey(2),

Haven't found any other ones yet, except that foxels to pixels doesn't seem to work exactly correctly. It is always of a few pixels and I haven't figured out why yet.

Best regards,
Rick C. Hodgin