On 2007-05-28, at 19:40 EDT, Benjamin Shine wrote:
If I have a class defined like this:
<class name="subclassbox" extends="happystyledbox">
<attribute name="bgcolor" value="navy" />
<attribute name="width" value="150" />
<attribute name="innerColor" value="blue" />
</class>
with a superclass
<class name="happystyledbox" width="70" height="70" bgcolor="$style
{'stylebgcolor'}" /> ...
and an instance
<subclassbox id="sb2" />
...when in the construction drama does the value of bgcolor on sb2
get looked up?
I'm finding that, for an instance sb2 of subclassbox, the superclass's
definition of bgcolor to a $style constraint is evaluated, but the
explicit value of bgcolor should be used instead.
The code for __LZapplyStyleMap carefully doesn't let a style
constraint override an explicit attribute as specified in the
arguments specified on the instance itself. I need to *also* block
the case where a style constraint from a superclass would override
an attribute set explicitly in a subclass. How can I figure out
what attributes are explicitly set somewhere in the superclass chain?
(I'm talking about legals, btw. This test already passes in trunk.)
This code:
// A style does not override an explicit attribute
if (! (k in initialArgs)) {
should keep any constraint from being applied. initialArgs should be
all the attributes of the instance, which should include bgcolor, so
no constraint should be applied. (The stylemap arg in applyStyleMap
is _all_ of the $style constraints of the instance and all of its
superclasses.)
See LPP-2894 and r3313 which fixed this in trunk (and should have
been applied to legal's).
