Thanks for your comments and thanks for the back channel screen shot. It does not tell me much though. I hesitate to suggest this but could this be a bug in FB or FBtoC? The code is not working for me because I can no longer count on getting the correct number of strings saved in a string resource. -Joe On May 25, 2009, at 7:52 PM, Brian Stevens wrote: > Joe, > > I ran your code to create the resource file with the same results. > Yes, big endian puts the most significant ( i.e. the byte with the > higher bit values such as 32,768, 16,384, 8192, 4096 etc. ) byte > ( only in multi-byte vars of course ) first. Since the "03" is in > the least significant byte ( coded in the 2 and 1 bits ), it would > be stored last on big-endian. The Apple Resource Manager is smart > and handles endian issues for standard resources, so it looks like > the 2 byte count var in your 'tempList' resource is stored as little > endian on disk. > In any event, the code is working. Be careful using FB resource > calls. Some such as DEF APNDSTR have been tweaked to do byte > swapping but others may not. BTW: I'm sending a screen > print( backchannel ) showing the resource file in HexEdit so you can > see what else is in this file. There is ( presumably ) overhead in > the first hex 103 bytes of this file. Your string data starts at hex > offset 103. These don't show up in Rezilla because it "understands" > resources. > > On May 25, 2009, at 2:46 PM, Joe Lertola wrote: > >> OK, I just looked it says: "Standard system-defined resource types >> (e.g. STR#, moov, MENU) are big-endian on disk." >> >> However when I run my demo the string resource looks like it is >> being save in little_endian format, not big_endian. Look at this >> Rezilla screen shot: >> >> http://www.joelertola.com/temp/res_prob.jpg >> >> There is a 3 in the first byte and a zero in the second byte. >> Big_endian should be the opposite I think. >> >> -Joe >> >> >> On May 25, 2009, at 5:13 PM, Brian Stevens wrote: >> >>> >>> On May 25, 2009, at 10:14 AM, Joe Lertola wrote: >>> >>>> Yes, I see that fixes it in this case. But doesn't it seem like >>>> there is a problem in the string resource if the byte order has >>>> to be swithched to big enden when running on an intel chip? >>> >>> Joe - look at "byte order on disk: resources" in the FBtoC Help in >>> the section on Byte Order. >>> >>> Brian S >>> >>> -- >>> To unsubscribe, send ANY message to: futurebasic-unsubscribe@... >>> >> >> >> = >> -- >> To unsubscribe, send ANY message to: futurebasic- >> unsubscribe@associate= >> .com >> >> = > > -- > To unsubscribe, send ANY message to: futurebasic-unsubscribe@... >
