Hi Piotr, I would want to understand how a child's getExplicitOrMeasuredWIdth ends up back at the TLC. So maybe investigate that more carefully. In theory, a child's explicit width or measuredWidth should not reference the parent.
But also note that the children scan in measuredWidth/Height is intended for a UIComponent made up of other UIComponents, like ComboBox. In many cases, we compose components out of other Basic non-UIComponents. I would expect the icon to not be a UIComponent. And thus the coercion to IUIComponent in that loop should fail. So if a TLC is not made up of UIComponents, then it might need a custom measuredWidth method, although in many cases so far, the computed offsetWidth is correct (or good enough), so mw!=0 (on line 2174) and you don't go into that children scan. HTH, -Alex On 10/25/19, 9:32 AM, "Piotr Zarzycki" <[email protected]> wrote: Hi Alex, I just get back to it. Ok you are right that this is definitely not a fix. I should bring that code back. However I believe I'm starting to understand what is actually happening. CheckBox and RadioButton has children which are being setup royale_wrapper = this. If I use measuredWidth property I end up at some point in following place [1]. TLC is being scan with it's children - when child exists we are taking getExplicitOrMeasuredWidth, which may end with using again measuredWidth cause getExplicitOrMeasuredWidth returns it. - Here is our "Maximum call stack size exceeded" issue. The question is should we getExplicitOrMeasuredWidth from children which has royale_wrapper = this ? [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2Fc8783287c3e37658ef942d81797eb5337025c127%2Fframeworks%2Fprojects%2FMXRoyale%2Fsrc%2Fmain%2Froyale%2Fmx%2Fcore%2FUIComponent.as%23L2180&data=02%7C01%7Caharui%40adobe.com%7Cd25295f06c9e459dc9fa08d75968e0aa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637076179315418772&sdata=5fN%2BbforHrBtzzIHJ3jupzBBJJNNE9FTymE1lMqf0I0%3D&reserved=0 Thanks, Piotr wt., 22 paź 2019 o 18:02 Alex Harui <[email protected]> napisał(a): > Responses in-line > > On 10/22/19, 1:52 AM, "Piotr Zarzycki" <[email protected]> wrote: > > Comments inline. > > pon., 21 paź 2019 o 18:25 Alex Harui <[email protected]> > napisał(a): > > > Then you will need to explain why the event handling code that uses > > royale_wrapper is not going to be invoked. Maybe there is no way to > > actually click on the icon (as opposed to the label next to the > icon)? > > > > > I just checked CheckBox and nothing has changed. I can click on every > element in CheckBox and it's being selected. > > Did you step through it in the debugger to make sure the target when > clicking on the icon element was the icon? > > > If you look through the code, I believe we set royale_wrapper on just > > about every child element in every other component. Creating an > exception > > must be justified. The actual solution (some sort of stack > overflow) might > > be better prevented by detecting the 'loop' of calls. We do that in > > several places already, like the layouts. > > > > > Yes we are, but why in case o checkbox royale_wrapper is being set to > children component (Icon in this case), as "this" ? > > royale_wrapper is used on all kinds of child elements in other components > to point to the top-level component (TLC). There is code that tries to > determine that the "CheckBox" component is the dispatcher of some event > even though the browser is going to say it was some HTMLElement. It is > effectively the back-reference from HTMLElements to the TLC. In Flash, you > could use mouseChildren and mouseTransparent to affect the event.target. > In Royale, we have APIs like Event.isSameTarget(). I'm having trouble > believing that isSameTarget is going to work if you pass in the icon. > > I think I've said this before, but IMO, there is a difference between > application coding and framework coding. When developing an application, > it is often ok for something to "just work" because that code only has to > work in that one application. In framework development, it can't just work > for the one application you happen to be working on, it has to work for > everyone else's application as well, so decision have to be based on > fundamental logic and there has to be much less (although probably not > zero) code that "just works". > > When I saw your change, my first thought was: "(almost) all child elements > should have a royale_wrapper set to the TLC, so why is this an exception?" > Somehow, we need framework developers to learn the common patterns in the > framework or go searching for them because having an exception to the rules > is usually a sign that the code isn't right, even if it appears to work for > some scenario. It will be a lot easier to teach other folks to be > framework developers and for them to learn how to debug the framework if > there is a consistent set of rules like "all child elements have > royale_wrapper set". > > I also looked at RadioButton and saw that it had its icon.royale_wrapper > set to the TLC. Is it working correctly? I grep'd the code for > royale_wrapper and saw how it was being used in lots of places and who was > reading it. And that got me thinking it was a definite pattern and your > change was an exception and while it may look like it "just works" it may > not later if there is some event dispatched off the icon and no > royale_wrapper to use to determine the TLC. Maybe if someone calls > isSameTarget on the event it will fail. > > My 2 cents, > -Alex > > > -- Piotr Zarzycki Patreon: *https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cd25295f06c9e459dc9fa08d75968e0aa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637076179315418772&sdata=QGprGzBDVRkoNyVlOS6WoREdXohjyRtN4aPbdh6fE94%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cd25295f06c9e459dc9fa08d75968e0aa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637076179315418772&sdata=QGprGzBDVRkoNyVlOS6WoREdXohjyRtN4aPbdh6fE94%3D&reserved=0>*
