Peter,

Forgive me for pointing out the obvious, but as your 2-D array has  
only 2 elements in the 2nd dimension, it can easily be replaced by  
two 1-D arrays. You'll have to use a conditional to determine which  
to access, but that shouldn't hamper anything.

#DEFINE SortType as STR255

BEGIN RECORD MaterialAlloc
DIM AS STR15     JobNo
DIM AS INT       Depth
DIM AS SortType  Endd0[1000]
DIM AS SortType  Endd1[1000]
END RECORD

Of course I still recommend replacing the string arrays with arrays  
of index values to a separate string array.

   e-e
   =J= a  y
    "


On Nov 12, 2008, at 1:19 AM, Robert Purves wrote:

>
> Peter wrote:
>
>>> #DEFINE SortType as STR255
>>>
>>> BEGIN RECORD MaterialAlloc
>>> DIM AS STR15     JobNo
>>> DIM AS INT       Depth
>>> DIM AS SortType  Endd(1000,1)
>>> END RECORD
>>>
>
> I wrote:
>> The old FB Compiler.app misbehaves if a record exceeds 32767 bytes.
>
>
> Another limitation seems to be that arrays inside records must be 1- 
> dimensional. This test gives compilation errors in FB4.
>
> '--------------
> begin record Test
> dim as long array2D[1, 1]
> end record
>
> dim as Test myTestVar
> dim as long j, k, n
> n = 0
> for j = 0 to 1
> for k = 0 to 1
> myTestVar.array2D[j, k] = n
> n++
> next
> next
>
> for j = 0 to 1
> for k = 0 to 1
> print myTestVar.array2D[j, k]
> next
> next
>
> stop
> '--------------
>
>
> In theory FBtoC should support 2D arrays inside a record. But they  
> are illegal in FB, so nobody writes such code, and so we have never  
> tested FBtoC against it. Not surprisingly, there turns out to be a  
> translation bug (it prevents access to the array field). Perhaps  
> surprisingly, the declaration itself is correctly translated:
>
> typedef struct  __attribute__ ((__packed__)) 	Test
> {
>   long              array2D[2][2];
> } Test;
>
> FWIW, the bug is fixed in the forthcoming version 1.1.6.
>
> Robert P.
>
> --
> To unsubscribe, send ANY message to: futurebasic- 
> unsubscribe@...
>
>