VariableStructureArrayField (again)

Blair,
    I'm not sure if this is covered by the previous problems with
VariableStructureArrayFields that you looked into a few weeks ago (to do
with the BITMAPINFO class #bmiColors: write accessor)?. I've now been trying
to define and use the ICONIMAGE structure, which uses _three_ VSAFs, and as
well as the write accessors the last two read accessors also appear to be
incorrect.

I've got around it by defining my own accessors, along with the instance
creation and #byteSize methods, so it's not a problem for me but I thought
it might be worth mentioning.

Ian

defineFields
    " ICONIMAGE compileDefinition "
self
    defineField: #icHeader type: (StructureField type: BITMAPINFOHEADER);
    defineField: #icColors type: (VariableStructureArrayField
            type: RGBQUAD
            length: #colorsCount);
    defineField: #icXOR type: (VariableStructureArrayField
            type: BYTE
            length: #xorCount);
    defineField: #icAND type: (VariableStructureArrayField
            type: BYTE
            length: #andCount)

Ian

You wrote in message news:kUEb6.195008$[hidden email]...
> ...
>     I'm not sure if this is covered by the previous problems with
> VariableStructureArrayFields that you looked into a few weeks ago (to do
> with the BITMAPINFO class #bmiColors: write accessor)?. I've now been
trying
> to define and use the ICONIMAGE structure, which uses _three_ VSAFs, and
as
> well as the write accessors the last two read accessors also appear to be
> incorrect.

It is partly the same problem - basically all write accessors generated by
VariableStructureArrayField will be incorrect as it is defined in 4.0 PL1. A
bodge patch is possible., but the proper fix is quite far reaching and
therefore a bit complicated to formulate into a patch, so I am intending to
leave it until the planned maintenance release.

As for the 2 and 3rd fields being incorrectly defined, that is because the
first field is of variable length and the ExternalStructure/ExternalField
framework does not automatically support anything other than a fixed offset
for the start of a field. This means that any fields (whether variable
length or not) that appear after a variable length field will need any
auto-generated accessors modified to account for their variable offset.
Generally this isn't an issue, since such structures are not representable
correctly using C structs either. Thankfully such structures are mercifully
rare, so it probably isn't worth the effort of enhancing Dolphin's field
accessor generation capabilities to support them directly.

Regards

Blair

Blair,

> It is partly the same problem - basically all write accessors generated by
> VariableStructureArrayField will be incorrect as it is defined in 4.0 PL1.
A
> bodge patch is possible., but the proper fix is quite far reaching and
> therefore a bit complicated to formulate into a patch, so I am intending
to
> leave it until the planned maintenance release.

OK. Thanks.

> Generally this isn't an issue, since such structures are not representable
> correctly using C structs either. Thankfully such structures are
mercifully
> rare, so it probably isn't worth the effort of enhancing Dolphin's field
> accessor generation capabilities to support them directly.

Fair enough. MS seem to be going the same way as, apart from the one source
I was using, the structure in question seems to have been completely purged
from MSDN anyway. I've also now found it's actually a lot easier to get the
Icon's "innards" by using the ICONINFO structure and then writing it back
into a file using a simple ByteArray. Problem solved <g>

Regards
    Ian