>
> > One of the first problems that I see BaseClass.c line 1868. This
> > determines whether or not the resource list needs to be de-compiled, or
> > simply copied. But a resource_offset will always be >= 0, since it is a
> > Cardinal, right??
>
> No. Two things: note the (int) cast in the conditional, and the
> comments in the else below it (see GetResList.c).
Good point :)
>
> I don't remember if I wrote this, or it came from Harald. Anyway,
> after the resources are "compiled" (which happens after the containing
> class is initialized), a subclass cannot just "copy" the resource
> list from the parent class. They have to be decompiled first.
> That's what all this crap is for. Gadgets use this so that subclasses
> of LabelG can merge their resource lists with those of the parent
> class.
So far so good....baseclass/test7 seems to be deciding that the resources do
not need to be decompiled, when in fact it seems that they do, at least things
look nicer if they are. Why don't we use the core_class variable class_inited
to determine if the resources need to be decompiled???
>
> I suppose there could be a problem if sizeof(Cardinal) > sizeof(int),
> but I would expect X to choke in this case too (truncation losing
> sign). The resource offset would have to be *huge*, though, so I
> don't think it likely.
>
> > > WRT to the 'VDX problem' I really look out for a more capable
> > > volunteer. I was sure having found the problem about 3 times,
> > > but finally had to learn I don't understand enough to make
> > > test/Xm/baseclass/test[5-7] work as "expected" (i.e. keep
> > > test 5,6 going as before and test 7 not crashing).
> > > As outlined earlier this still won't match the Motif results,
> > > but that's another story here.
>
> Mitch
>
>
