You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Neverbirth <ne...@gmail.com> on 2014/11/20 22:10:01 UTC
Re: Determining which MXML elements are containers
I added support for DefaultProperty today, but there are many cases to check
to make sure everything is supported as expected.
Well, at any rate this is a nice improvement, many cases where the
completion list wasn't showing any type are now working, but there are cases
still showing more than they should and a few missing cases.
Gordon and/or Darrell didn't drop by, which is a bit of a shame as it would
ease all of the process.
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Determining-which-MXML-elements-are-containers-tp41370p42583.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: Determining which MXML elements are containers
Posted by Héctor A <ne...@gmail.com>.
That's some great info Gordon. Once I finish some of my current tasks I'll
look again into MXML.
I'm working with the old compiler in mind, I'd love to see Falcon finished,
and being able to use it for code completion would be great if it proves to
be fast enough. Using the compiler services is how code completion works by
default for Haxe in FlashDevelop.
I'd like to help improving Falcon and any other of the Apache Flex
projects, but sadly don't have the time for it right now...
On Sat, Dec 13, 2014 at 10:30 PM, Gordon Smith <gs...@hotmail.com> wrote:
>
> I have a few points to belatedly make on this thread:
>
> 1. The 'specifications' folder of the 'flex-external' repository has a
> spec for MXML 2006 and 2009. It's incomplete, but it's the best one that
> exists. If you find that it doesn't answer your questions about which
> elements are allowed inside which elements, please let me know where
> specific information is missing or wrong and I'll try to improve the spec.
>
> 2. In the new Falcon compiler, MXMLNodeBase, the abstract base class for
> all nodes in the MXML syntax tree, has a method called processChildTag()
> which gets overridden in each subclass to process the allowed child tags
> (i.e., elements). For example, if you look at this method in
> MXMLDeclarationsNode (which represents <fx:Declarations>) you can see that
> MXMLComponentNode (representing <fx:Component>), MXMLModelNode
> (representing <fx:Model>), and MXMLInstanceNode (representing tags like
> <s:Button> and <fx:int>) are allowed, while all other tags are disallowed.
> Since Falcon hasn't been completed, this may or may not match the logic in
> the old compiler and in the spec, but the information still may be of some
> use to you. In any case, if you're using Falcon, your code hinting will
> match what the compiler allows. Are you working to incorporate Falcon into
> an IDE, or the old compiler?
>
> 3. In my opinion, code-hinting logic belongs in Falcon, and it would be
> great it you would add it there rather than in one particular IDE. Falcon
> was always intended to be a code-intelligence engine to support IDE
> editing, and not just a compiler.
>
> - Gordon
>
>
Re: Determining which MXML elements are containers
Posted by Darrell Loverin <da...@gmail.com>.
Setting the itemRenderer goes thru the same error checking as any other
assignment statement so that why there is no special case error checking
code for IFactory. There is special handling for IFactory. For the inline
MXML assignment to itemRenderer the compiler generates a "new
ClassFactory()" and assigns that to itemRenderer. It is easier to
understand if you look at the generated AS code by adding "-keep" to the
command.
Below are some methods that might help you understand what is happening:
*See references to StandardDefs.isIFactory().
*See the TypeCompatibility.check() method in the MXML compiler.
Hope that helps,
-Darrell
-Darrell
On Fri, Dec 5, 2014 at 9:29 AM, Darrell Loverin <da...@gmail.com>
wrote:
> I'll have some time this weekend to look at this a bit.
>
>
> -Darrell
>
> On Thu, Dec 4, 2014 at 3:29 AM, Héctor A <ne...@gmail.com> wrote:
>
>> Hello again Darrell, and sorry for bothering one more time,
>>
>> I've been browsing the MXMLC source looking for IFactory info, but I
>> couldn't find what I need. How do I determine the type of class/interface
>> expected by an IFactory? is it posible or must I add it case by case? I've
>> seen that when the type value is defined as a child tag it allows for other
>> IFactory types as expected:
>>
>> <s:List>
>> <s:itemRenderer>
>> <custom:CustomFactory/>
>> </s:itemRenderer>
>> </s:List>
>>
>> However, when defining it as an attribute it allows for clases
>> implementing IItemRenderer as well:
>>
>> <s:List itemRenderer="CustomRenderer"/>
>>
>> Is it possible to get the correct type dynamically? I haven't find
>> anything on either the SDK or compiler source, so it may not be possible
>> and implemented in the IDE itself.
>>
>> Best regards,
>>
>>
>> On Tue, Nov 25, 2014 at 3:47 AM, Darrell Loverin <
>> darrell.loverin@gmail.com> wrote:
>>
>>> >>Right now none because the property is private, and if it wasn't,
>>> just subclasses.
>>> That sounds right to me.
>>>
>>>
>>> -Darrell
>>>
>>> On Sun, Nov 23, 2014 at 8:34 PM, Héctor A <ne...@gmail.com> wrote:
>>>
>>>>
>>>> >>property of type NavigationStack, marked with [ExcludeClass], what
>>>>> does that mean?
>>>>>
>>>>> [ExcludeClass] prevents FlashBuilder from hinting the class and
>>>>> excludes it from ASDoc.
>>>>>
>>>>> I know, I guess I made myself not too clear. I meant with regards to
>>>> children nodes auto-completion, subclasses may not be excluded, but again,
>>>> the default property is marked private, and at least in fd case the
>>>> property info is not always available. So, which class types could appear
>>>> in that case? None? NavigationStack subclasses? Right now none because
>>>> the property is private, and if it wasn't, just subclasses.
>>>>
>>>
>>>
>>
>
RE: Determining which MXML elements are containers
Posted by Gordon Smith <gs...@hotmail.com>.
I have a few points to belatedly make on this thread:
1. The 'specifications' folder of the 'flex-external' repository has a spec for MXML 2006 and 2009. It's incomplete, but it's the best one that exists. If you find that it doesn't answer your questions about which elements are allowed inside which elements, please let me know where specific information is missing or wrong and I'll try to improve the spec.
2. In the new Falcon compiler, MXMLNodeBase, the abstract base class for all nodes in the MXML syntax tree, has a method called processChildTag() which gets overridden in each subclass to process the allowed child tags (i.e., elements). For example, if you look at this method in MXMLDeclarationsNode (which represents <fx:Declarations>) you can see that MXMLComponentNode (representing <fx:Component>), MXMLModelNode (representing <fx:Model>), and MXMLInstanceNode (representing tags like <s:Button> and <fx:int>) are allowed, while all other tags are disallowed. Since Falcon hasn't been completed, this may or may not match the logic in the old compiler and in the spec, but the information still may be of some use to you. In any case, if you're using Falcon, your code hinting will match what the compiler allows. Are you working to incorporate Falcon into an IDE, or the old compiler?
3. In my opinion, code-hinting logic belongs in Falcon, and it would be great it you would add it there rather than in one particular IDE. Falcon was always intended to be a code-intelligence engine to support IDE editing, and not just a compiler.
- Gordon
Re: Determining which MXML elements are containers
Posted by Darrell Loverin <da...@gmail.com>.
I'll have some time this weekend to look at this a bit.
-Darrell
On Thu, Dec 4, 2014 at 3:29 AM, Héctor A <ne...@gmail.com> wrote:
> Hello again Darrell, and sorry for bothering one more time,
>
> I've been browsing the MXMLC source looking for IFactory info, but I
> couldn't find what I need. How do I determine the type of class/interface
> expected by an IFactory? is it posible or must I add it case by case? I've
> seen that when the type value is defined as a child tag it allows for other
> IFactory types as expected:
>
> <s:List>
> <s:itemRenderer>
> <custom:CustomFactory/>
> </s:itemRenderer>
> </s:List>
>
> However, when defining it as an attribute it allows for clases
> implementing IItemRenderer as well:
>
> <s:List itemRenderer="CustomRenderer"/>
>
> Is it possible to get the correct type dynamically? I haven't find
> anything on either the SDK or compiler source, so it may not be possible
> and implemented in the IDE itself.
>
> Best regards,
>
>
> On Tue, Nov 25, 2014 at 3:47 AM, Darrell Loverin <
> darrell.loverin@gmail.com> wrote:
>
>> >>Right now none because the property is private, and if it wasn't, just
>> subclasses.
>> That sounds right to me.
>>
>>
>> -Darrell
>>
>> On Sun, Nov 23, 2014 at 8:34 PM, Héctor A <ne...@gmail.com> wrote:
>>
>>>
>>> >>property of type NavigationStack, marked with [ExcludeClass], what
>>>> does that mean?
>>>>
>>>> [ExcludeClass] prevents FlashBuilder from hinting the class and
>>>> excludes it from ASDoc.
>>>>
>>>> I know, I guess I made myself not too clear. I meant with regards to
>>> children nodes auto-completion, subclasses may not be excluded, but again,
>>> the default property is marked private, and at least in fd case the
>>> property info is not always available. So, which class types could appear
>>> in that case? None? NavigationStack subclasses? Right now none because
>>> the property is private, and if it wasn't, just subclasses.
>>>
>>
>>
>
Re: Determining which MXML elements are containers
Posted by Héctor A <ne...@gmail.com>.
Hello again Darrell, and sorry for bothering one more time,
I've been browsing the MXMLC source looking for IFactory info, but I
couldn't find what I need. How do I determine the type of class/interface
expected by an IFactory? is it posible or must I add it case by case? I've
seen that when the type value is defined as a child tag it allows for other
IFactory types as expected:
<s:List>
<s:itemRenderer>
<custom:CustomFactory/>
</s:itemRenderer>
</s:List>
However, when defining it as an attribute it allows for clases
implementing IItemRenderer as well:
<s:List itemRenderer="CustomRenderer"/>
Is it possible to get the correct type dynamically? I haven't find
anything on either the SDK or compiler source, so it may not be possible
and implemented in the IDE itself.
Best regards,
On Tue, Nov 25, 2014 at 3:47 AM, Darrell Loverin <da...@gmail.com>
wrote:
> >>Right now none because the property is private, and if it wasn't, just
> subclasses.
> That sounds right to me.
>
>
> -Darrell
>
> On Sun, Nov 23, 2014 at 8:34 PM, Héctor A <ne...@gmail.com> wrote:
>
>>
>> >>property of type NavigationStack, marked with [ExcludeClass], what does
>>> that mean?
>>>
>>> [ExcludeClass] prevents FlashBuilder from hinting the class and excludes
>>> it from ASDoc.
>>>
>>> I know, I guess I made myself not too clear. I meant with regards to
>> children nodes auto-completion, subclasses may not be excluded, but again,
>> the default property is marked private, and at least in fd case the
>> property info is not always available. So, which class types could appear
>> in that case? None? NavigationStack subclasses? Right now none because
>> the property is private, and if it wasn't, just subclasses.
>>
>
>
Re: Determining which MXML elements are containers
Posted by Darrell Loverin <da...@gmail.com>.
>>Right now none because the property is private, and if it wasn't, just
subclasses.
That sounds right to me.
-Darrell
On Sun, Nov 23, 2014 at 8:34 PM, Héctor A <ne...@gmail.com> wrote:
>
> >>property of type NavigationStack, marked with [ExcludeClass], what does
>> that mean?
>>
>> [ExcludeClass] prevents FlashBuilder from hinting the class and excludes
>> it from ASDoc.
>>
>> I know, I guess I made myself not too clear. I meant with regards to
> children nodes auto-completion, subclasses may not be excluded, but again,
> the default property is marked private, and at least in fd case the
> property info is not always available. So, which class types could appear
> in that case? None? NavigationStack subclasses? Right now none because
> the property is private, and if it wasn't, just subclasses.
>
Re: Determining which MXML elements are containers
Posted by Héctor A <ne...@gmail.com>.
> >>property of type NavigationStack, marked with [ExcludeClass], what does
> that mean?
>
> [ExcludeClass] prevents FlashBuilder from hinting the class and excludes
> it from ASDoc.
>
> I know, I guess I made myself not too clear. I meant with regards to
children nodes auto-completion, subclasses may not be excluded, but again,
the default property is marked private, and at least in fd case the
property info is not always available. So, which class types could appear
in that case? None? NavigationStack subclasses? Right now none because the
property is private, and if it wasn't, just subclasses.
Re: Determining which MXML elements are containers
Posted by Darrell Loverin <da...@gmail.com>.
>>property of type NavigationStack, marked with [ExcludeClass], what does
that mean?
[ExcludeClass] prevents FlashBuilder from hinting the class and excludes it
from ASDoc.
-Darrell
On Sun, Nov 23, 2014 at 6:49 PM, Darrell Loverin <da...@gmail.com>
wrote:
> I not sure how complete the MXML support in the falcon compiler so I
> checked the old mxmlc compiler. The old mxmlc validates with specialized
> if/else statements based on parent and child types for elements that do not
> provide [DefaultProperty]. For example, here is a code snippet from
> ComponentBuilder.ComponentChildNodeHandler.nestedDeclaration():
>
> // Halo navigators (Accordion, TagNavigator, and
>
> // ViewStack) only support container based children.
>
> if (checkHaloNavigatorRequirements &&
>
> standardDefs.isHaloNavigator(parentType) &&
>
> !standardDefs.isNavigatorContent(childType) &&
>
> !(child instanceof ReparentNode))
>
> {
>
> log(child, new
> HaloNavigatorsRequireHaloContainerChildren());
>
> }
>
> See the whole method for all the checks.
> Also see the checks in DocumentChildNodeHandler.nestedDeclarations() as
> well.
>
> Hope this helps,
>
>
> -Darrell
>
> On Fri, Nov 21, 2014 at 11:51 AM, Héctor A <ne...@gmail.com> wrote:
>
>> Thank you very much for the reply Darrell, your help would be highly
>> appreciated. I have some doubts, and I guess some more will be popping up,
>> but if I can avoid having to find out about them the less time it will take
>> to have a better IDE.
>>
>> I've seen ViewNavigatorApplication and ViewNavigator has
>> [DefaultProperty("navigationStack")] , which is a private property of type
>> NavigationStack, marked with [ExcludeClass], what does that mean? right now
>> it renders DefaultProperty to be null, which I suppose is the right thing
>> to do.
>>
>> How are the possible fx: types for a node determined? is there a set of
>> rules determined? after a root node, a fx:Declaration element, a component
>> declaration, an ItemRenderer... is it hacked around? I guess so, but I'll
>> have to think about how to handle those special cases properly.
>>
>> I haven't looked into Flex 3 in depth yet.
>>
>>
>> On Fri, Nov 21, 2014 at 2:31 PM, Darrell Loverin <
>> darrell.loverin@gmail.com> wrote:
>>
>>> Sorry I missed this thread. Using [DefaultProperty] and
>>> [ArrayElementType] sounds right for Spark components but I don't see
>>> [DefaultProperty] declared in mx containers and I don't remember how mx
>>> containers were validated. I'll investigate to see how it works this
>>> weekend.
>>>
>>>
>>> -Darrell
>>>
>>> On Thu, Nov 20, 2014 at 4:38 PM, Héctor A <ne...@gmail.com> wrote:
>>>
>>>> Cc-ing Gordon and Darrell here, in case they missed this thread.
>>>>>
>>>>
>>>> Thanks, that would be the better source of information and the best way
>>>> to make sure I implement everything as it should.
>>>>
>>>> I didn't mention it, but of course I added support for ArrayElementType
>>>> and InstanceType metas as well, although I didn't test any case where it is
>>>> used inside a SWC yet, so it may fail in that case.
>>>>
>>>> I'll need to come up with every example and test case possible,
>>>>
>>>
>>>
>>
>
Re: Determining which MXML elements are containers
Posted by Héctor A <ne...@gmail.com>.
Thanks for the tip, it will be rather helpful when the time comes, right
now I've hit some sort of roadblock, I've extended support for
ArrayElementType and DefaultProperty, and I've seen the more classes FD has
to check, the more time it takes to check type constraints. There isn't any
sort of cache for it, and I have to check the complete inheritance chain
for every type every time, so I'll have to come up with something.
On Mon, Nov 24, 2014 at 12:49 AM, Darrell Loverin <darrell.loverin@gmail.com
> wrote:
> I not sure how complete the MXML support in the falcon compiler so I
> checked the old mxmlc compiler. The old mxmlc validates with specialized
> if/else statements based on parent and child types for elements that do not
> provide [DefaultProperty]. For example, here is a code snippet from
> ComponentBuilder.ComponentChildNodeHandler.nestedDeclaration():
>
> // Halo navigators (Accordion, TagNavigator, and
>
> // ViewStack) only support container based children.
>
> if (checkHaloNavigatorRequirements &&
>
> standardDefs.isHaloNavigator(parentType) &&
>
> !standardDefs.isNavigatorContent(childType) &&
>
> !(child instanceof ReparentNode))
>
> {
>
> log(child, new
> HaloNavigatorsRequireHaloContainerChildren());
>
> }
>
> See the whole method for all the checks.
> Also see the checks in DocumentChildNodeHandler.nestedDeclarations() as
> well.
>
> Hope this helps,
>
>
> -Darrell
>
> On Fri, Nov 21, 2014 at 11:51 AM, Héctor A <ne...@gmail.com> wrote:
>
>> Thank you very much for the reply Darrell, your help would be highly
>> appreciated. I have some doubts, and I guess some more will be popping up,
>> but if I can avoid having to find out about them the less time it will take
>> to have a better IDE.
>>
>> I've seen ViewNavigatorApplication and ViewNavigator has
>> [DefaultProperty("navigationStack")] , which is a private property of type
>> NavigationStack, marked with [ExcludeClass], what does that mean? right now
>> it renders DefaultProperty to be null, which I suppose is the right thing
>> to do.
>>
>> How are the possible fx: types for a node determined? is there a set of
>> rules determined? after a root node, a fx:Declaration element, a component
>> declaration, an ItemRenderer... is it hacked around? I guess so, but I'll
>> have to think about how to handle those special cases properly.
>>
>> I haven't looked into Flex 3 in depth yet.
>>
>>
>> On Fri, Nov 21, 2014 at 2:31 PM, Darrell Loverin <
>> darrell.loverin@gmail.com> wrote:
>>
>>> Sorry I missed this thread. Using [DefaultProperty] and
>>> [ArrayElementType] sounds right for Spark components but I don't see
>>> [DefaultProperty] declared in mx containers and I don't remember how mx
>>> containers were validated. I'll investigate to see how it works this
>>> weekend.
>>>
>>>
>>> -Darrell
>>>
>>> On Thu, Nov 20, 2014 at 4:38 PM, Héctor A <ne...@gmail.com> wrote:
>>>
>>>> Cc-ing Gordon and Darrell here, in case they missed this thread.
>>>>>
>>>>
>>>> Thanks, that would be the better source of information and the best way
>>>> to make sure I implement everything as it should.
>>>>
>>>> I didn't mention it, but of course I added support for ArrayElementType
>>>> and InstanceType metas as well, although I didn't test any case where it is
>>>> used inside a SWC yet, so it may fail in that case.
>>>>
>>>> I'll need to come up with every example and test case possible,
>>>>
>>>
>>>
>>
>
Re: Determining which MXML elements are containers
Posted by Darrell Loverin <da...@gmail.com>.
I not sure how complete the MXML support in the falcon compiler so I
checked the old mxmlc compiler. The old mxmlc validates with specialized
if/else statements based on parent and child types for elements that do not
provide [DefaultProperty]. For example, here is a code snippet from
ComponentBuilder.ComponentChildNodeHandler.nestedDeclaration():
// Halo navigators (Accordion, TagNavigator, and
// ViewStack) only support container based children.
if (checkHaloNavigatorRequirements &&
standardDefs.isHaloNavigator(parentType) &&
!standardDefs.isNavigatorContent(childType) &&
!(child instanceof ReparentNode))
{
log(child, new
HaloNavigatorsRequireHaloContainerChildren());
}
See the whole method for all the checks.
Also see the checks in DocumentChildNodeHandler.nestedDeclarations() as
well.
Hope this helps,
-Darrell
On Fri, Nov 21, 2014 at 11:51 AM, Héctor A <ne...@gmail.com> wrote:
> Thank you very much for the reply Darrell, your help would be highly
> appreciated. I have some doubts, and I guess some more will be popping up,
> but if I can avoid having to find out about them the less time it will take
> to have a better IDE.
>
> I've seen ViewNavigatorApplication and ViewNavigator has
> [DefaultProperty("navigationStack")] , which is a private property of type
> NavigationStack, marked with [ExcludeClass], what does that mean? right now
> it renders DefaultProperty to be null, which I suppose is the right thing
> to do.
>
> How are the possible fx: types for a node determined? is there a set of
> rules determined? after a root node, a fx:Declaration element, a component
> declaration, an ItemRenderer... is it hacked around? I guess so, but I'll
> have to think about how to handle those special cases properly.
>
> I haven't looked into Flex 3 in depth yet.
>
>
> On Fri, Nov 21, 2014 at 2:31 PM, Darrell Loverin <
> darrell.loverin@gmail.com> wrote:
>
>> Sorry I missed this thread. Using [DefaultProperty] and
>> [ArrayElementType] sounds right for Spark components but I don't see
>> [DefaultProperty] declared in mx containers and I don't remember how mx
>> containers were validated. I'll investigate to see how it works this
>> weekend.
>>
>>
>> -Darrell
>>
>> On Thu, Nov 20, 2014 at 4:38 PM, Héctor A <ne...@gmail.com> wrote:
>>
>>> Cc-ing Gordon and Darrell here, in case they missed this thread.
>>>>
>>>
>>> Thanks, that would be the better source of information and the best way
>>> to make sure I implement everything as it should.
>>>
>>> I didn't mention it, but of course I added support for ArrayElementType
>>> and InstanceType metas as well, although I didn't test any case where it is
>>> used inside a SWC yet, so it may fail in that case.
>>>
>>> I'll need to come up with every example and test case possible,
>>>
>>
>>
>
Re: Determining which MXML elements are containers
Posted by Héctor A <ne...@gmail.com>.
Thank you very much for the reply Darrell, your help would be highly
appreciated. I have some doubts, and I guess some more will be popping up,
but if I can avoid having to find out about them the less time it will take
to have a better IDE.
I've seen ViewNavigatorApplication and ViewNavigator has
[DefaultProperty("navigationStack")] , which is a private property of type
NavigationStack, marked with [ExcludeClass], what does that mean? right now
it renders DefaultProperty to be null, which I suppose is the right thing
to do.
How are the possible fx: types for a node determined? is there a set of
rules determined? after a root node, a fx:Declaration element, a component
declaration, an ItemRenderer... is it hacked around? I guess so, but I'll
have to think about how to handle those special cases properly.
I haven't looked into Flex 3 in depth yet.
On Fri, Nov 21, 2014 at 2:31 PM, Darrell Loverin <da...@gmail.com>
wrote:
> Sorry I missed this thread. Using [DefaultProperty] and [ArrayElementType]
> sounds right for Spark components but I don't see [DefaultProperty]
> declared in mx containers and I don't remember how mx containers were
> validated. I'll investigate to see how it works this weekend.
>
>
> -Darrell
>
> On Thu, Nov 20, 2014 at 4:38 PM, Héctor A <ne...@gmail.com> wrote:
>
>> Cc-ing Gordon and Darrell here, in case they missed this thread.
>>>
>>
>> Thanks, that would be the better source of information and the best way
>> to make sure I implement everything as it should.
>>
>> I didn't mention it, but of course I added support for ArrayElementType
>> and InstanceType metas as well, although I didn't test any case where it is
>> used inside a SWC yet, so it may fail in that case.
>>
>> I'll need to come up with every example and test case possible,
>>
>
>
Re: Determining which MXML elements are containers
Posted by Darrell Loverin <da...@gmail.com>.
Sorry I missed this thread. Using [DefaultProperty] and [ArrayElementType]
sounds right for Spark components but I don't see [DefaultProperty]
declared in mx containers and I don't remember how mx containers were
validated. I'll investigate to see how it works this weekend.
-Darrell
On Thu, Nov 20, 2014 at 4:38 PM, Héctor A <ne...@gmail.com> wrote:
> Cc-ing Gordon and Darrell here, in case they missed this thread.
>>
>
> Thanks, that would be the better source of information and the best way to
> make sure I implement everything as it should.
>
> I didn't mention it, but of course I added support for ArrayElementType
> and InstanceType metas as well, although I didn't test any case where it is
> used inside a SWC yet, so it may fail in that case.
>
> I'll need to come up with every example and test case possible,
>
Re: Determining which MXML elements are containers
Posted by Héctor A <ne...@gmail.com>.
>
> Cc-ing Gordon and Darrell here, in case they missed this thread.
>
Thanks, that would be the better source of information and the best way to
make sure I implement everything as it should.
I didn't mention it, but of course I added support for ArrayElementType and
InstanceType metas as well, although I didn't test any case where it is
used inside a SWC yet, so it may fail in that case.
I'll need to come up with every example and test case possible,
Re: Determining which MXML elements are containers
Posted by OmPrakash Muppirala <bi...@gmail.com>.
Thanks for the update!
Cc-ing Gordon and Darrell here, in case they missed this thread.
Thanks,
Om
On Thu, Nov 20, 2014 at 1:10 PM, Neverbirth <ne...@gmail.com> wrote:
> I added support for DefaultProperty today, but there are many cases to
> check
> to make sure everything is supported as expected.
>
> Well, at any rate this is a nice improvement, many cases where the
> completion list wasn't showing any type are now working, but there are
> cases
> still showing more than they should and a few missing cases.
>
> Gordon and/or Darrell didn't drop by, which is a bit of a shame as it would
> ease all of the process.
>
>
>
> --
> View this message in context:
> http://apache-flex-development.2333347.n4.nabble.com/Determining-which-MXML-elements-are-containers-tp41370p42583.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>