I forgot about someone overriding setStyle. Right, so what about a method
like setStyleInState()?
I'm thinking of supporting both styles and properties.
If it's a style we create a mx.states.SetStyle and for properties we create
a mx.states.SetAction and add to the state's overrides array.
On Thursday, March 12, 2015, Alex Harui <aha...@adobe.com> wrote:
>
>
> On 3/12/15, 1:39 PM, "jude" <flexcapaci...@gmail.com <javascript:;>>
> wrote:
>
> >OK now I see the states generated code. I've seen this before. Right, it's
> >creating a new SetStyle instance. It's creating that at the document
> >level.
> >I hear your points and they are valid. I think we could work around it.
>
> I agree. I just wanted to make sure you understood the current mechanism.
>
> >
> >But I think it will be OK to modify setStyle().
>
> Well, anyone who has overridden setStyle in a third party component will
> break as soon as you change the signature. That’s just the way AS and the
> VM work. It is true that any existing calls to setStyle can continue to
> work, but IMO, the upheaval in third-party components is too high to be
> making a change to setStyle’s parameter list. It is probably better just
> to add a new method.
>
> > // do new stuff here - Alex writes this part
>
> Uhh, no. Judah’s going to write this part ;-)
>
> >
> >The part where it says do new stuff here we could dynamically create the
> >mx.states.setStyle action and add it to the overrides. Or we dynamically
> >create the new CSSCondition("pseudo", "up"); and create a new selector.
> >There would be the possibly for the same property or style to be assigned
> >twice as you mentioned. We could create a warning, throw an error at
> >runtime or just let the last one in win.
> >
>
> Is this just limited to styles or are you going to allow setting regular
> properties? If the latter, then I think you are trying to add to the set
> of overrides.
>
> -Alex
>
>
