Good input.
If I understand your scenario (and maybe you or someone can post a small
but real-world scenario), it supports my thinking that, instead of more
ways to use State, that the currentState property should just be thought
of as another organizing property, and the conditional setting of values
should be somehow determined by any property on a component, not just
currentState. Then if you had an orientation property or maybe
"isLandscape" then you would create conditional expressions to determine
what to do.
-Alex
On 6/3/13 8:22 AM, "Bill Turner" <bi...@firstpac.com> wrote:
>State groups are pretty much the question in reverse - they allow you to
>group related states together, but you still have to set the currentState
>as the combination.
>
>I've seen this myself mostly when trying to deal with mobile apps and the
>rotation capabilities of a view. If you want to use the orientation and
>another state set, it's not as easy as it could be.
>
>Ultimately, I ended up doing something like Jude mentions, setting the
>current state to a combination of the "substates":
>
> private var _orientation:String; // landscape or portrait
> private var _displayAs:String: // the "real" state
> public function set orientation(value:String):void {
> _orientation = value;
> super.setCurrentState(_orientation + '_' + _displayAs);
> }
>
>It would be nice if there was some way to combine the substates. In
>particular, in this case the built-in orientation management of the
>mobile doesn't combine automatically, as it's checking if "landscape" and
>"portrait" are states, so there's some workaround that's required
>anyway...
>
>I had wondered about something like what Cosma suggested on the
>declaration - but the setting of the combined states still is cumbersome
>and requires the app to manage the sub-states itself rather than having
>the framework help.
>
>Maybe something like:
>
> <s:states>
> <s:ExclusiveStateGroup id="mouse">
> <s:State name="up"/>
> <s:State name="down"/>
> <s:State name="over"/>
> </s:ExclusiveStateGroup>
> <s:ExclusiveStateGroup id="focus">
> <s:State name="nonFocused"/>
> <s:State name="focused"/>
> </s:ExclusiveStateGroup>
> <s:ExclusiveStateGroup id="selection">
> <s:State name="nonDefault"/>
> <s:State name="default"/>
> </s:ExclusiveStateGroup>
> </s:states>
>
> currentState.mouse = "up" // Change just the mouse group
>state
>
>I agree that having too many substates says there's something wrong, but
>this could help with some meaningful state combinations like orientation
>and an app-specific state.
>
>Bill Turner
>Enterprise Software Engineer
>First Pacific Corporation
>(503) 588-1411 ext. 2303
>bi...@firstpac.com
>
>-----Original Message-----
>From: John Cunliffe [mailto:mahn...@gmail.com]
>Sent: Saturday, June 01, 2013 4:41 AM
>To: dev@flex.apache.org
>Subject: Re: Multidimensional States
>
>How is that different from the already existing
>stateGroups<http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e
>3d11c0bf63611-7ffa.html>property?
>
>
>On Sat, Jun 1, 2013 at 12:28 PM, jude <flexcapaci...@gmail.com> wrote:
>
>> I've been coming across more and more cases where it would be great to
>>have
>> support for multidimensional states. What this looks like and how it's
>>used
>> I'm not sure. Maybe we can discuss ideas.
>>
><<snip>>
>
>________________________________
>
>Confidentiality Notice: This page and any accompanying documents contain
>information that is confidential, privileged, or exempt from disclosure
>under applicable law and is intended for the exclusive use of the
>addressee. This information is private and protected by law. If you are
>not the intended recipient, you are hereby notified that any disclosure,
>copying, distribution, or use of the contents of this information in any
>manner is strictly prohibited.
