Hi Andrew, don't think so. I think "currentState" is a missing capability from Flex States, don't know what Alex think about it, but seems something to add to States.
This is more a bug at some point, in states? in ClassSelectorList? is a lack of implementation in Jewel components? maybe Alex that knows more about States could bring some light on this. thanks El sáb., 15 sept. 2018 a las 0:45, Andrew Wetmore (<[email protected]>) escribió: > Could one deal with this issue for now by creating a global "currentState" > property and referencing it on state change? > > On Fri, Sep 14, 2018 at 7:29 PM Carlos Rovira <[email protected]> > wrote: > > > Hi Alex, > > > > the issue comes from beads modifying strand className. This can be seen > > mixing states with jewel layouts. Jewel Layouts add or removes class > names > > in the strand at runtime. > > Since, as you describe in the example, those changes are not part of some > > state (i.e: className.normal or className.someState, for example), the > > current class name is not stored anywhere, so when you change the state > and > > comes back, Royale is not capable of recreate the right strand className > > > > You can see the issue in action if you compile the blog example about > > states [1] > > > > > > > https://github.com/apache/royale-asjs/tree/develop/examples/blog/BE0008_Using_View_States_to_show_or_hide_content > > > > Compile the example and run (online version works ok due to it was > > published when the work was in unfinished stated) > > > > Then push the button to change state from login form to result screen and > > push the button back to go to the other state. You'll see the layout is > not > > equal. If check the html in the broswer, you'll find class names are lost > > between state changes. > > > > What do you think would be a good solution to this problem? > > > > thanks > > > > Carlos > > > > > > > > > > > > El vie., 14 sept. 2018 a las 18:23, Alex Harui (<[email protected] > > >) > > escribió: > > > > > Regarding class selectors and states, I guess I don't understand the > > > issue. The code behind Royale (and Flex) states should be capturing > > values > > > of properties changed by the state before they get changed, then > > restoring > > > those properties. IOW, if you were to have > > > > > > <js:states> > > > <js:state name="normal" /> > > > <js:state name="important" /> > > > <js:states> > > > <j:Button id="myButton" emphasis.normal="primary" > > > emphasis.important="emphasized" /> > > > > > > Then the myButton.emphasis="primary" at startup and when the state > > > changes to "important" the States impl should read myButton.emphasis > and > > > store that value away before setting myButton.emphasis="emphasized". > > Then, > > > when the state changes back to "normal", the States impl should set > > > myButton.emphasis="primary" again. > > > > > > In the implementation for the emphasis property, if it involves > changing > > > classLists, the implementation must do so in a way that handles having > > the > > > emphasis property changes at runtime. The States impl isn't really > doing > > > anything application developer code might do, so the implementation > must > > > support properties being set and re-set. > > > > > -- > > Carlos Rovira > > http://about.me/carlosrovira > > > > > -- > Andrew Wetmore > > http://cottage14.blogspot.com/ > -- Carlos Rovira http://about.me/carlosrovira
