Xojo reverses Data on Windows (not little endian)

Xojo reverses Data on Windows (not little endian)

How to read the data properly in a Memoryblock to show ‘00 00 00 0D’ hex as ‘13’ decimal?
When trying to read a small PNG file, the IDE reads the binary stream of the PNG file correctly, and places the data in a MemoryBlock correctly. The correct data is shown below when a breakpoint at ‘Dim x as Integer’ is created.
Figure 1. Correct format and data order of PNG file.

When the first 8 bytes of PNGHeader.PNGSignature are read and shown with EncodeHex, the data is in the correct order, which is ‘89 50 4E 47 0D 0A 1A 0A’.

When trying to view the next 4 bytes ’00 00 00 0D’ the value should be decimal 13 or hex D. The value instead shows as decimal 218103808, or hex 00 D0 00 00.


Here is the Xojo program, and the 2x2.png file that can be downloaded:
Download PNG1.zip

What am I missing to show the correct value of hex 00 00 00 0D?

Thank you :slight_smile:

I just tried this on macOS 12.3.1 (M1) in Xojo 2022r1.1 using a random PNG on my desktop, and I get the same result:

1 Like
 Structure PNGHeader
   PNGSignature as String * 8
   IHDRLengthBytes as String * 4 // not CString
 End Structure

Var m As MemoryBlock = PNGStruct.IHDRLengthBytes
m.LittleEndian = False
Var n As Uint32 = m.UInt32Value(0) // Stored as BigEndian comes 13

Hello Rick,

Thank you, as it works.

It seems like a second memoryblock is needed to reverse the mixed numbers of the original memoryblock.

As an example the 00 00 00 0D is in the original memoryblock correctly according to the breakpoint as a string. When trying to view a UInteger32, the number is reversed. Adding another memoryblock then reverses the reversal (does that make sense?).

Thanks :slight_smile:

Your first memory block is using Little Endianess as default byte ordering, the struct 00 00 00 0D for 13 is clearly Big Endian (Big first, little last) so I just created a second one to keep whatever you are doing untouched, and read the value informing Xojo to consider a Big Endian layout for such 4 bytes in memory.

1 Like

Another way to capture such value skipping the creation of another MemoryBlock, is reading it directly from the first one, as

Data.LittleEndian = False // big endian

Var n As Uint32 = Data.UInt32Value(8) // get that 13 stored there

Yes, your right, that code will also work.

Its a shame that the Structure doesn’t work as intended. An intermediate conversion step is needed. This appears to be a bug.

Here is some solution code based on helpful information from @Rick_A

It works as designed, your intention needs a new feature, informing endianess for each field

something like

Structure PNGHeader
  PNGSignature as String * 8
  IHDRLengthBytes as Uint32 BigEndian
End Structure

Yes, a new feature would eliminate the extra steps. :slight_smile:

1 Like