| Title: | *OLD* ALL-IN-1 (tm) Support Conference |
| Notice: | Closed - See Note 4331.l to move to IOSG::ALL-IN-1 |
| Moderator: | IOSG::PYE |
| Created: | Thu Jan 30 1992 |
| Last Modified: | Tue Jan 23 1996 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4343 |
| Total number of notes: | 18308 |
We just found a nasty little bug in V3 after spending many hours tracing this down. It broke my expense report program. My app had 2 fields, called E1 qnd E2. An init script was doing a GET on all the fields to preload some symbols, like get #null = er_page1.%open['1'] Get #e1 = .e1 get #e2 = .e2 get #telephone = .telephone etc... get .%close #E1 and #E2 were always getting loaded with the literal string .E1 (or .E2) instead of the field value. If you just do a <GET Ennn..n where nnn..n is any all-digits sequence, instead of an error, or symbol not found, it just returns the Ennnnn back as a string literal!! So Get E1111 puts E1111 on line 24, or into your symbol assignment, etc. Very nasty. Adding any letter like E111A returns it to normal behaviour. I had to go into all my code and replace the E1 and E2 with ENT1 & ENT2, and it is now working correctly again. Anyone can test this - you don't even need a form with a field named Exxx. Just do the <GET test from the choice field on a menu. This bug must be in the V3 command parser. The app worked fine under V2.4. Could someone in Engineering verify this bug and offer an explanation of how/why its happening? Regards, Al
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2438.1 | ALL-IN-1 thinks it's a scientific number | IOSG::SHOVE | Dave Shove -- REO2-G/M6 | Fri Mar 19 1993 13:56 | 18 |
Well, the reason for this is that ALL-IN-1's symbol processing thinks
you've given it a numeric literal in the scientific notation.
Strings such as 1e5 are accepted (just as Fortan and similar languages
do). GETs of such literals just return them as they stand - no
processing is done on them until you do a COMPUTE or similar.
It seems that the symbol processor thinks that E111 is in this format,
(and in fact COMPUTE interprets it as 0E111, i.e. zero).
Whether this is a bug, and whether it will get fixed, I'm not sure. The
documentation doesn't seem to define the exact format of a literal
number. However, if we change it so that E5 isn't accepted as a number,
we'll probably break something! (As it happens, our development system
contains such a change, as a side-effect of another change! I don't
know if this change will get out into the field though.)
D.
| |||||
| 2438.2 | Interesting why it didn't break in V2.4!?! | GANTRY::HULL | Digital Services Delivery - Motown | Fri Mar 19 1993 16:12 | 7 |
Thanks for the insight, Dave. I guess forewarned is forearmed....I'll never use Ennn as a field name again! -Al P.s. I went in and changed my "exponential" field names to something else and they work fine now. | |||||
| 2438.3 | It's a bug | IOSG::SHOVE | Dave Shove -- REO2-G/M6 | Fri Mar 19 1993 16:57 | 11 |
On re-reading your .0, I realise that you said this was introduced in
v3.0
That's more than likely, as there were lots of changes to the symbol
processor in 3.0 (40 changes major enough to warrant incrementing the
module's version number!)
So I guess that makes it a bug, which means that it will "go on our
list to be fixed". Don't know when you'll see the fix though.
D.
| |||||