views:

2077

answers:

3

Every now and then I get an error when I set up states in an MXML file. The error I get says that mx:states could not be resolved to a component implementation.

I read, at the following url, that this issue is caused by extending components - that somehow throws off the compiler's ability to resolve mx:states. I don't see why this should be the case, but I don't have any answer of my own. I also can't necessarily make this approach work with all of my extended components.

http://life.neophi.com/danielr/2007/01/could_not_resolve_to_a_compone.html

The workaround I've come up with is to not use any namespace. So, my code then looks like this:

<states>...</states>

rather than:

<mx:states>...</mx:states>

Making this stranger (at least, to me) is the fact that the children of the tag - - does not have this issue. mx:states can not be resolved, but its child mx:State can. And mx:SetProperty - a child of mx:State - is also resolved.

Can anyone explain this, and/or offer a better solution to the problem than what I've come up with?

Incidentally, I see the same issue with mx:transitions.

+7  A: 

If you have a custom component, you'll probably have it in a namespace other than mx. You're on the right track by removing the namespace, but you don't have to do that. Consider the following example

<example:MyComponent xmlns:mx="http://www.adobe.com/2006/mxml"
    xmlns:example="com.example.*">
</example:MyComponent>

In that code, we have a custom component named MyComponent in the com.example package. Now, how do we add custom states? It's easy!

<example:MyComponent xmlns:mx="http://www.adobe.com/2006/mxml"
    xmlns:example="com.example.*">

    <example:states>
        <mx:State name="CustomState">
        </mx:State>
    </example:states>

</example:MyComponent>

Properties of a component, like states, transitions, or even label on a Button can be created as child elements. Those properties must use the same namespace as the component instance. It doesn't matter where the property comes from in the inheritance chain. Even if com.example.MyComponent extends mx.containers.Canvas, the states property will use the XML namespace in which MyComponent is defined.

In short, don't think of the states property as mx:states because the mx: prefix of a property is merely inherited from the component. However, we do have to use mx: when we define the actual state itself because that's a class (not a property) and that class is defined in the mx namespace.

To go a step further in the explanation, you can change the http://www.adobe.com/2006/mxml namespace to be something other than mx.

<zzz:VBox xmlns:zzz="http://www.adobe.com/2006/mxml"&gt;
    <zzz:states>
    </zzz:states>
</zzz:VBox>

In that example, we change mx to zzz. Now, the states property has to be prefixed with zzz: instead of mx:.

joshtynjala
Josh,Thanks for the reply. Can you explain further why mx is not a valid namespace in a component that extends a component implementing that namespace? And why is this not an issue for, say, mx:Button?
Ross Henderson
Actually, I didn't meant 'why mx is not a valid namespace' -- I meant, why is 'mx:states not resolvable'.
Ross Henderson
Thanks for the additional clarification, Josh. Sorry so long in accepting.
Ross Henderson
Excellent reply - StackOverflow was down so I had to figure this our myself and I did, but that's exactly the problem I had, and it is not covered anywhere in the docs..
Michael Pliskin
A: 
<mx:VBox xmlns:mx="http://www.adobe.com/2006/mxml"
         width="100%" 
         height="100%"
         backgroundColor="#f7f7f7" 
         xmlns:common="com.americanexpress.voice.view.component.common.*">
    <mx:states name="edit">

Why does this fail? I have also found that this fails when I have multiple namespaces defined. Remove the <mx: addresses the issue.

A: 

Thanks, very helpful!

Zoia