>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 "