OK. Does anyone have any ideas, contributions or feature requests before I
look into this further?
Do any of the compiler guys have any thoughts? I was going to ask Gordon
Smith for his thoughts here but legend has it the only way to contact him
is to type his name 3 times into command line at mid
On 3/15/15, 10:42 PM, "jude" wrote:
>OK so we would add an overrides array on UIComponent and when the state is
>changing check for any overrides and apply them?
No idea exactly what to do here. I think there are several choices:
-Adding another property to UIComponent
-Adding a data structur
OK so we would add an overrides array on UIComponent and when the state is
changing check for any overrides and apply them? Then in the compiler when
we encounter a pseudo state attribute we add these to the instance's
overrides array?
On Sat, Mar 14, 2015 at 10:21 PM, Alex Harui wrote:
>
>
> On
On 3/14/15, 10:36 AM, "jude" wrote:
>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.SetActio
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 Th
On 3/12/15, 1:39 PM, "jude" 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
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'm not saying there won't be conflicts but there are conflicts now with
CS
Hi Judah,
I think your example from a few posts ago didn’t actually have a
state-dependent attribute. Maybe try something like this:
I think there might be too many backward-compatibility risks with changing
the API signature of setStyle. The compiler could certainly generate a
call to
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); // cr
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
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
Hi Judah,
I didn’t read your entire post. 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 looks and consider
whether it would change your mind about what you want to do.
-Alex
O
What is the subtree? Do you mean that a CSS declaration,
"s|Button#myButton" would match a button named myButton in two different
documents or views? Yeah, that's a possibility.
I looked at the generated code and here is the MXML and generated code for
an ImageButton class:
generates:
private
First of all, technically, you are sort of trying to do this:
The Button itself may not have an icon property, and the Button itself
doesn’t have a set of states like “up”.
So, setting the currentState on Button may not have any effect, and might
not have an effect if the Skin itsel
Hmm. I don't have any problem with using the "icon.up" in the MXML skin.
I'm thinking of the occasion in the example.
We could still declare the states property changes generated code as part
of the document except when we set a skin state we set the component
instance.currentState instead of curr
Interesting. I get why you would want that.
States are declared as part of the document. So “icon.about” tells the
compiler to set the icon when the MXML file changes currentState to
“about”. The Button skin, if it were defined in MXML, would have the “up”
state, not necessarily the MXML file t
This sounds like a fantastic idea. It would be a bonus if we could get the
same state names auto-complete feature to work in CSS as well.
Thanks,
Om
On Mar 7, 2015 8:08 PM, "jude" wrote:
> In CSS you can address certain states of a component using pseudo states
> (states) like so:
>
> s
In CSS you can address certain states of a component using pseudo states
(states) like so:
s|Button#iconOnlyButton:up {
icon: "assets/upImage.png";
}
s|Button#iconOnlyButton:over {
icon: "assets/overImage.png";
}
s|Button#iconOnlyButto
18 matches
Mail list logo
