Alain, you are correct in stating that I should use the correct type identifier. I may be the only one that thinks this way but I'll say it anyway. When variable suffixes could be eliminated for type identifiers I was under the belief that the "&" and LONG were identical. Until I ran into the problem with the GWorlds, everthing worked exactly as I thought. After crashing a whole lot for no apparent reason I tried what seemed like a silly idea to change to a suffix. It appeared to work most of the time. I sent Staz a note to the same effect, asking for a technote. I thought that others might be under the same misconception. W. -----Original Message----- From: Alain Pastor [mailto:apastor@...] Sent: Wednesday, April 11, 2001 4:44 PM To: futurebasic@... Subject: Re: [FB] "AS LONG" vs & Chris Stasny wrote: > >% > > > >Hi Waverly, > > > > > When I switched from defining the variable theGWorld AS LONG > > > to theGWorld& 99% of my crashes went away. > > > >Wow, I've touted the &-pill as analgesic relief for > >pain-in-the-brain. But you seem to have applied & in the > >realm of voodoo, the occult, and buggggzzs. > > > >Magical! > > > >LS > > Items with an ampersand (&) are taken as pointers. Items without > ampersand are taken as records. If you want to slap an offset on the > end of a generic long integer variable, you will have to use a > variable with an ampersand. > > EXAMPLE (Old style pointer) > > DIM TEhndl& > > top = TEhndl&..teViewRect.Top% : REM this works > > Or (new style record) ... > > DIM TEHndl as ^^TErec > > top = TEhndl..viewRect.top : REM this works > > DIM TEhndl AS LONG > > top = TEhndl..viewRect.top% : REM compiler gets confused here > > In the last case FB has to start guessing. Is TEHndl the record or > does it point to the record? > > This is an imperfect example off the top of my head, but the moral of > the story is this: If you are going to use offsets other that those > in true records, you should stick with an ampersand. > > Your example is almost good except that for the demonstration you should have used an example with a pointer instead of a handle I guess. Because the following lines : DIM TEhndl AS LONG top = TEhndl..viewRect.top% : REM compiler gets confused here won't compile at all with an undefined constant error. However, Edwards' statement is somewhat misleading. One can think that he is saying there is an obscure bug in the DIM AS LONG clause that can be cured using the & symbol. It seems that his problem was due to the use of an incorrect variable type, using a long instead of a pointer, therefore his statement might have been as well : "When I switched from defining the variable theGWorld AS LONG to theGWorld AS PTR 99% of my crashes went away." Another moral for the same story could be: If you are going to get rid of the type identifiers in your code be prepared to use the correct type for your variables as well as the correct field names for your records. I bet this is a good candidate for a technote.