>Hi,
>
>I sent this contribution to this thread several days ago while my ISP was
>messed up. I can't tell that it was received, so here it is again. Please
>excuse if you've already seen this:
>======================
>Subject:     Re: [FB] FN RESERROR
>Sent:        11/24/98 3:19 PM
>To:          FB list, futurebasic@...
>
>>However. I never use XREF, not it's @ cousin, as they seem too
>>much fuss. What's wrong with grwowing your own handles, then you
>>can check, length and overwriting, and you know where you are?
>>XREF just seems a level of indirection that can create confusion
>>and error... As this original post would imply...
>>
>>jonathan
>>
>I respectfully disagree. XREF@ adds structure, not indirection. It's
>simply the elegant way of doing exactly what you are suggesting. Granted,
>you still have to do the checking, but you have to do that in any case.
>
>Essentially, what the XREF statements do is allow you to use FB's robust
>array-handling routines on memory that you specify, rather than on memory
>that you explicitly allocate with a DIM array(10,20) statement. It
>eliminates the need to pass (i.e., copy) arrays between functions, because
>you can just pass their handles (or pointers).
>
>I'd bet an icecream cone (2 scoops!) that for regular-length data (%, &,
>etc., or records), my XREF@ code will be shorter and probably more elegant
>than your "home-grown" handle code.
>
>¢¢
>
> 0"0
> =J= a  y
>  "             (more below)
>===============================
>
>>I define a record...
>>DIM RECORD testRec
>> DIM testFirstEntry%
>> DIM testSecondEntry&
>> DIM 25 testThirdEntry$
>>DIM END RECORD.testRec
>>
>>Then I use ( 3*_testRec + _testThirdEntry) type constructions
>>the put and get the info in the handle. This seems as intuitive
>>as I need. I'm not saying XREFs is not good, just that they
>>seem to create confusion (would they be a hangover from a
>>time when there was no support for handles and pointers in FB?)
>>and thus I have never perceived that the gain I could obtain
>>from using them would exceed the investment in time and grey
>>matter to grok and debug the little thingies (This is of course
>>a reflection on the bad quality of my grey matter, not on XREF,
>>but my point was that if others have similar 'conceptual' problems
>>with XREF, there are other techniques...)
>>
>>jonathan
>
>And if you need 1000 entries? I know you're not short on gray matter, but
>maybe you need a primer:
>
>You understand arrays, yes?
>You understand handles and pointers, yes?
>
>XREF and XREF@ merely put arrays into pointers and handles, respectively.
>
>To use XREF@,
>
>'1. Set up variables to hold handles
>  DIM myXArray&, myHandle&
>
>'2. Allocate some space for the array. Let's assume 100 Long integers,
>'   so the size needs to be 100*4 = 400
>  myHandle& = FN NEWHANDLE(400) 'You would do this to grow your own anyway
>
>'3. Dimension the array using XREF@ (exactly like a DIM statement)
>  XREF@ myXArray&(99)  'Use same name, so FB knows which handle to use
>
>'4. Tell FB where to find the array
>  myXArray& = myHandle&
>
>You're done! myXArray&(n) is exactly like any other array you've ever
>DIMmed, except that it is located at [myXArray&].   (Which is also
>[myHandle&].)
>
>What may get confusing is that if you want to use another (_any_ other)
>array of long integers in a handle, you can do so just by providing the
>handle:
>  myXArray& = myOtherHandle&
>This is the equivalent of BLOCKMOVEing one array into the space of
>another, except nothing has to be moved except the handle, and the
>original array isn't demolished in the process.
>
>When you "grow your own," you're duplicating functions that are available
>in FB, and which have been tested and proven a lot more than yours.
>
>I hope this adds more clarity than confusion.
> 0"0
> =J= a  y
>  "

This list is fine . I just begin to understand the XREF mechanism and the
advantage to use it.

However, I often have to work with numerical data structured in tables of
varying dimensions, not known at compile time. For example, my user may
acquire data sent on 1 to 8 (but perhaps 15 in the future) channels during
varying time at a given sampling rate (Numbers are laying contiguously in a
handle, the next sampling after the last USED channel). My application is
has to be able to access each of these values. The use of XREFerencing
whould imply that data should be displayed in an structure created
differently whether the number of channel is something like:

select chanNb
	case 1
		XREF@ myXArray&(40000)
	case 2
		XREF@ myXArray&(40000,1)
	case 3
		XREF@ myXArray&(40000,2)
..........................
end select

It doesn't seem very handy and the syntax is not homogenous.(what about
XREF@ myXArray&(40000,0) ). For the moment I prefer keep my own grown
structure.

The only QuickBasic feature I don't find in FB (and I regret) is the true
dynamical allocation of memory

DIM A&(n%,m%,p%)

I however like FB

########################################################
# Guy Bonnot              phone: +33 - 04 72 43 79 82  #
# INRA - INSA               fax: +33 - 04 72 43 85 34  #
# Biologie 406           internet: bonnot@... #
# 20, av. A. Einstein                                  #
# 69621 Villeurbanne cedex                             #
# France                                               #
########################################################