The ST_TEST structure contains members which are unformatted headers or containers for the actual lower-level fields. In fact, every structure has this issue with the first member, being the name of the overall structure rather than a proper member. So in the for/next loop, the print statement to print dstest.@fnames$(1) is equivalent to trying to print dstest itself, most like resulting in unintelligible garbage due to the mixture of field types, embedded raw binary bytes, etc. So, in general when iterating through the fields of a dynstruct, you probably want to skip the first one. In addition, the ST_TEST structure has a member (price) which itself a structure (ST_PRICE). It would make little sense to try print that structure as if it were a single printable entity. One way to avoid this kind of problem is to refer back to the field attributes in the flddefs() array and avoid attempts to print members that are themselves structures or perhaps any member of type X. The following improved version of the for/next loop printing the fields illustrates a couple of approaches to that test:
! sample retrieval/display using indirect deferred syntax
! (with logic to avoid printing members of type X or with sub-members)
for i = 1 to fields
if (flddefs(i).vartyp and VARTYP_MASK) = VARTYP_X then
repeat ! skip X vars
elseif (i < fields) and flddefs(i+1).pos = flddefs(i).pos then
repeat ! skip vars with sub-layouts
else
? dstest.@fnames$(i) ! print only non-X, non-multilevel
endif
next i
Note that the test above for two adjacent fields with the same starting position, while a perfectly valid way to detect when a field is actually just a header for a collection of subfields, probably won’t come into play because in virtually all cases, those top-level fields would be of type X (covered by the first test). The exception would be an overlay, but in that case, the overlaid members may not be adjacent.
