>What dings me between the ears is why gOffSet&=3 instead of gOffSet&=0 or
>gOffSet&=2 is needed (although I assume it has to be because the first 2
>bytes are giving the number of strings).  And why gOffSet& = gOffSet& + 49
>instead of gOffSet& = gOffSet& + 48 works.  The original suggestion I was
>given was gOffSet&=0 and then gOffSet& = gOffSet& + 48, but I had to do the
>above to get the correct use.
>
Terrald,

I'm only guessing now, but it appears that when strings are stored in 
STR# resources, they don't get pad bytes. The simple solution? Add a char 
to your strings, so they are 49 bytes long. Then when the length byte 
gets added, they'll be 50 bytes each; then my "one fell swoop" solution 
should work!

DIM 49 DIAGNOSIS$(_numberOfStrings)      'FB will add length byte
'Copy entire array in 1 fell swoop
StrHndl& = FN GETRESOURCE(_"STR#",_diagnosislistSTR)
LONG IF StrHndl&
  BLOCKMOVE [StrHndl&]+2,@DIAGNOSIS$(0),FN GETHANDLESIZE(StrHndl&)-2
END IF

I don't know if this will make your data unusable, but there should be a 
simple way to work around it. Simplest would be to just remove the extra 
char when you use a string, but you could also loop through the array, 
poking 48's in each length byte after bringing in the data, then replace 
them with 49's before writing them back to the resource.

As for the odd offset, I couldn't say. Have you tried looking at the 
resource handle in MacsBug to see where the first length byte is? I'm 
curious, but don't have time to check it out.

I hope this will get you another step closer. Let me know how it fares.
 0"0
 =J= a  y
  "