Re: MXML attributes, minification, and initialization

I think our choices are to not allow any public vars in MXML Components, or to warn folks if they use public vars that are primitive types. I guess I don't care too much which way folks want to go. Sounds like the first options, I would probably choose the second. Let's see what others think.

Re: MXMLDataInterpreter

In my structure, tab would focus the first button and hitting tab again will focus the next button. Seems like normal behavior to me. > On Dec 6, 2017, at 9:16 PM, Alex Harui wrote: > > IMO, there are user expectations on how focus and selection will work. In >

Re: MXML attributes, minification, and initialization

> On Dec 6, 2017, at 9:19 PM, Alex Harui wrote: > > On 12/6/17, 10:01 AM, "Harbs" wrote: > >> Yes. I think we are saying the same thing. It’s curious that assignment >> on declaration makes a difference. > > I don't think we are saying the

Re: List, MDL Table - How to remove all content

Just to give an idea of where this is going. I've taken DataItemRendererFactorForArrayList and turned it into three beads: RefreshItemRenderersBead. This bead listens for dataProviderChanged and replaced all of the itemRenderers in the IItemRendererParent with fresh copies. It does this using

Re: MXML attributes, minification, and initialization

On 12/6/17, 10:01 AM, "Harbs" wrote: >Yes. I think we are saying the same thing. It’s curious that assignment >on declaration makes a difference. I don't think we are saying the same thing. Did you actually look at the output code? I'm pretty sure if you assign

Re: MXMLDataInterpreter

On 12/6/17, 12:40 AM, "Harbs" wrote: >>> >>> Agreed, but I can’t think of a way to do this. >> >> One way is to have assignable removeElement logic. > >Meaning an assignable Function property, or something else? Yes: public function removeElement(e:IUIBase):void {

Re: MXML attributes, minification, and initialization

In [1], you might need JSDoc for the class function (@constructor, for example). Back to your original test case: If you don't initialize the var myProp in your test case, what code is generated for these snippets we've been looking at? I would expect that GCC still renames myProp and whatever

ValueEvent

A heads up: I changed the signature of ValueEvent to take the value as the second argument of the constructor rather than the fourth argument. It looks like there were a couple of bugs in framework code which seemed to assume it was already the second argument… Harbs

Re: SingleSelectionContainerBead (was Re: MXMLDataInterpreter)

You can mix and match. Anything that implements ISelectable should be considered a “toggle button”. > On Dec 6, 2017, at 4:37 PM, Peter Ent wrote: > > Ha. Just sent a reply on the other thread with pretty much the same thing > that you did. Might be nice addition for

Re: SingleSelectionContainerBead (was Re: MXMLDataInterpreter)

Ha. Just sent a reply on the other thread with pretty much the same thing that you did. Might be nice addition for Express. Just in-line the things you want to toggle. Would it work with a ToggleButton, a CheckBox, and a couple of RadioButtons or do all of the children have to be ToggleButtons?

Re: MXMLDataInterpreter

Sometimes you really just want a set of buttons to act like a toggle button bar. There's nothing dynamic about them. Putting them into an container (I would recommend Group over Container since its much lighter in weight and you probably don't need the possibility of scrolling). The

SingleSelectionContainerBead (was Re: MXMLDataInterpreter)

OK. I’m done with the SingleSelectionContainerBead and committed it. Here’s a sample of how to use it: https://paste.apache.org/KG0k It’s intelligent enough to allow adding non-ISelectable components to a container and the index and selection management will

RE: MXML attributes, minification, and initialization

>For some reason, when this code is output, the code gets minified I guess the question is why the code gets mifinied if it’s annotated with @export. I’m not sure it’s related but when I compile this [1] file with gcc I get an internal compiler error [2]. When replacing in [1]

Re: MXML attributes, minification, and initialization

Here’s my reading of the issue: For some reason, when this code is output, the code gets minified to create a minified property which is assigned the value of the non-minified one. Considering a boolean is immutable, changing the value of myProp does not change the value of of the minified

Re: MXMLDataInterpreter

>> >> Agreed, but I can’t think of a way to do this. > > One way is to have assignable removeElement logic. Meaning an assignable Function property, or something else? > Another is to have a bead that overwrites UIBase.prototype.removeElement. > What won't work on SWF but will on JS.

RE: MXML attributes, minification, and initialization

This the js output. /** * @export * @type {boolean} */ components.MyComp.prototype.myProp = false; From: Alex Harui Sent: Tuesday, December 5, 2017 7:31:54 PM To: dev@royale.apache.org Subject: Re: MXML attributes, minification,

Re: MXMLDataInterpreter

On 12/5/17, 11:23 PM, "Harbs" wrote: >Responses inline: > >> On Dec 6, 2017, at 7:07 AM, Alex Harui wrote: >> >>> 3 There is no even being dispatched for removeElement. If I’m attaching >>> event listeners when they are added, I should be