[futurebasic] Re: [FB] Passing Arrays again...

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : October 2002 : Group Archive : Group : All Groups

From: Alain Pastor <pixmix@...>
Date: Sat, 19 Oct 2002 12:25:42 +0200

Jay wrote:
> Hello FB-ers:
>    I'm looking for the (a) way of passing arrays (and their bounds) to 
> another function.  I believe that I have seen an example from Staz, but I 
> cannot find it now.  I have tried all the permutations that I think of 
> right off but none seem to work.  Short of making the array(s) global or 
> using PEEK and POKE, I find that it is difficult to specify the name and 
> bounds of the array when using handles, ptrs, or XREFs in that they all 
> seem to require that the name and/or bounds be known to the calling 
> and/or target FN at compile time. I'd like to be able to index the array  
> in the Array(x,y) fashion at both ends of the call and return.
>    I'm blocked.  I give up.  How should it be done?
>    The snippet below is a silly but illustrative example.  Thank you 
> (anyone) in advance for helping with this.   Hayden Coon
> 
> Hayden,
> 
> To work with 2-dimensional arrays, FB must know at compile time what size 
> the array groups will be. That makes it impossible to use FB arrays that 
> change size within a FN as you are trying to do.
> 
> The work-around is to calculate your own offsets into a 
> single-dimensional array. The following code is not as pretty as what you 
> wished for, but it gets the job done.
> 
>  e-e
>  =J= a  y
>   "
> 
> 'Passing Arrays?
> 
> LOCAL FN PrintArrayAndModify(@address, length, wide)
> DIM AS INT m, n
> XREF genericArray(_maxlong) AS BYTE
> genericArray = address
> FOR m = 0 TO length
> FOR n = 0 TO wide
> PRINT genericArray((wide + 1) * m + n);
> NEXT n
> PRINT 'new line
> NEXT m
> genericArray((wide + 1) * 3 + 3) = 117 'modify array after printing
> END FN
> 
> clear LOCAL FN LoadArrays
> DIM First(4,3) AS BYTE
> DIM Second(5,4) AS BYTE
> DIM AS INT m,n
> 
> FOR m=1 TO 4
> FOR n=0 TO 3
> First(m,n) = 99
> NEXT n
> NEXT m
> 
> FOR m=0 TO 5
> FOR n=1 TO 4
> Second(m,n) = 11
> NEXT n
> NEXT m
> 
> //send them off for printing and check to see what we got
> PRINT:PRINT " The First Array ="
> FN PrintArrayAndModify(First(0,0),4,3)
> PRINT "First(3,3)=";First(3,3)'should be 117
> 
> PRINT:PRINT " The Second Array ="
> FN PrintArrayAndModify(Second(0,0),5,4)
> PRINT "Second(3,3)=";Second(3,3)'should be 117
> 
> END FN
> 
> '~Main
> 
> WINDOW 1
> FN LoadArrays
> 
> '-----------------
> DO
> HANDLEEVENTS
> UNTIL 0
> '-----------------
> 

Why I'm not surprised that Jay comes up with an elegant solution? 
However, there is a little bug in the code that will show up for some 
reason only with 68K compile. The following line:

LOCAL FN PrintArrayAndModify(@address, length, wide)

should read:

LOCAL FN PrintArrayAndModify(@address&, length, wide)

notice the ampersand appended to the address variable.

The code I sent was more cumbersome but more flexible too, in the 
sense that you can pass arrays with different item types. BTW, I left 
inadvertantly the declaration of a variable that was not required. You 
can safely remove from the code the following statement:

DIM AS PTR startOfnInArray
-- 
Cheers,

A. Pastor