I wrote: > > At any rate, the "XREF @ gList.MyRec(_bazillion)" statement does > > nothing, because it's only meaningful if there's a "DIM gList&" or a > > "DIM gList%;4" statement somewhere along with it, to define gList& (or > > gList%) as a global variable, which is to contain the handle. In > > particular, XREF@ doesn't reserve any space for anything. David replied: > I have no idea if my solution has got through, but I'd like to comment on > Rick's answer to this non-functioning solution. > > I can follow your logic here, but I have a bit of a problem with the fact > that the code for XREF@ #1.BAS which explains the .Top& workaround does not > do what you suggest. It seems to work - why? > > Iive attempted to post a solution - which seems to bounce - which does work > but does not use the .top& workaround. Now I'm really confused! Okay, I've done some experimenting, and I now have another asessment of what's happening: It looks like the statement "XREF@ myArray.myRecSize(_maxIndex)" does in fact reserve some space (even though it's not _supposed_ to. This is a bug.) It reserves one record of size _myRecSize, and calls that record myArray. So, if _myRecSize is 20, the XREF@ statement reserves 20 bytes on the stack, and VARPTR(myArray) will return the address of the first of those 20 bytes. When you then execute a statement like, "myArray.Top& = FN NEWHANDLE(...)," the handle to the block is stored into the first 4 of those bytes. The remaining 16 bytes (to use my example numbers) are not used. It is _not_ necessary to have a separate "DIM myArray;4" statement to reserve 4 bytes for the handle, as I had previously thought. When you subsequently make references to the _array_ called myArray, FB looks into the (non-array) _record_ called myArray, expecting to find a handle in the first 4 bytes. It uses that handle to figure out where the array's elements are. To make things more confusing: if you happen to explicitly DIM a long integer called myArray& _before_ the XREF@ statement, then FB assigns the _same_location_ in memory to the 4-byte myArray& variable and the 20-byte (or whatever) myArray _record_. You can verify this by printing VARPTR(myArray&) and VARPTR(myArray). That means that, in this case, you can assign the handle either to myArray& (the long int) or to myArray.Top& (the first 4 bytes of the record). Since they both occupy the same memory, the effect is the same. On the other hand, if you say "DIM myArray&" _after_ the XREF@ statement (or if you omit the "DIM myArray&" altogether), then FB assigns two _different_ locations to the long int myArray& and the 20-byte record myArray. In this case, you _must_ assign the handle to myArray.Top&; it won't work if you assign in to myArray&. As far as I can tell, all of the above applies only to arrays of _records_ defined with XREF@. If you use XREF@ to define an array of a "simple" type, as in "XREF@ myArray%(32)", then FB does not create that phantom record. In this case, you should assign the handle to the long int variable (i.e. to myArray&). All of the above applies to XREF as well as to XREF@. However, there is an additional problem with XREF which doesn't occur with XREF@. If XREF defines an array of records where each record has multiple fields, then FB does not correctly calculate the addresses of the 2nd and subsequent fields in each element. A reference to "myArray.field2&(n)" in this case likely to cause a crash.