The TL;DR was what if we treat inline pseudo states MXML like it is an
inline style or like we treat CSS pseudo style declarations? When we
encounter an attribute formatted like so, icon#up="myUpIcon.png" we,
meaning the compiler, write out:
temp.setStyle("icon", "myUpIcon.png", "up", true); // create a css pseudo
condition for the "up" state
Normally if we encounter a style inline we write out:
temp.setStyle("icon", "myUpIcon.png"); // generated by the compiler for the
inline style. see the previous email
We would have to add support by adding additional parameters to setStyles
for different states in the setStyle method at the very least.
Basically, <s:Button id="myButton" icon#up="myUpIcon.png" /> would be the
same as writing this:
s|Button#myButton:up {
icon:"myUpIcon.png"
}
which is the same as or similar to:
condition = new CSSCondition("pseudo", "up");
style =
styleManager.getStyleDeclaration("com.flexcapacitor.controls.ImageButton:up");
style.factory = function():void
{
this.icon = "myUpIcon.png";
};
But we create that code above specifically for that button instance at
runtime when setStyle("icon", "myUpIcon.png", "up", true) is called. We
might even be able to get rid of some generated style declarations if we
can use setStyle() to create the CSSConditions.
@Kessler - I didn't notice that method before. I'll check it out.
@Alex - I'll look at the states generated code again too. There might be
collisions with the states generated code.
you wrote,
"I think you missed some of the generated code for the state-dependent
properties and styles. Take a look at how the assignment for a
state-dependent style attribute look"
I'm looking at the generated files and I don't see anything. What MXML
would generate this or what files should I be looking for? In my last
message I copied in the generated code for an MXML declared Spark Button
and the generated code for a CSS declaration for a pseudo state. Both of
the codes appeared in the generated application file,
PseudoStatesExample-generated.as. Is this the same as what you were
referring to? Sorry the original was so long.
On Tue, Mar 10, 2015 at 9:41 AM, Alex Harui <aha...@adobe.com> wrote:
> Maybe, but the way the code currently works is that the states are
> declared in an MXML document and all state-dependent data is generated for
> that same document. While that state-dependent code does set styles and
> properties on other instances declared in that document, some of those
> instances are themselves MXML documents for which their state-dependent
> code has already been generated, probably when it was compiled into a SWC.
> There’s no way to modify that generated code, so we need a different way
> to determine when a state changes in a child object (yes, there events for
> that) and then make the appropriate changes and figure out how to deal
> with potential conflicts and what to do if the child object (or actually,
> its skin) doesn’t support the state you think it does.
>
> -Alex
>
> On 3/10/15, 4:53 AM, "Kessler CTR Mark J" <mark.kessler....@usmc.mil>
> wrote:
>
> >Is this something that could be accomplished by overriding the
> >stateChanged[1] protected method since it's used for setting styles when
> >the state changes?
> >
> >[1]
> >
> http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/mx/core
> >/UIComponent.html#stateChanged()
> >
> >
> >-Mark
>
>
