I may not be understanding the problem, but I assumed from Greg's description that the issue is that custom event classes with extra properties like IndexChangeEvent do not get those properties in the handler. I think the test case Yishay posted will work because there is no test for the custom class or property.
ElementEvents is setup for Basic to provide the most lightweight and fast implementation. Some built-in HTML widgets send a "change" event, so why not listen directly for it? I think the emulation classes could instead choose to delete "change" from ElementEvents so that the "change" event is not assumed to come from the HTMLElement. Then the handful of emulation classes that need the "change" event from HTMLElement would listen for it and re-dispatch it. If that works, then folks won't have to go find and replace "change" in the code. HTH, -Alex On 12/20/20, 4:21 AM, "Yishay Weiss" <[email protected]> wrote: The difference I see in our app is that we are using RL’s eventMap.mapListener() and my example is using some mxml inline handler. Maybe this warrants investigation from that angle. From: Yishay Weiss<mailto:[email protected]> Sent: Friday, December 18, 2020 3:30 PM To: [email protected]<mailto:[email protected]> Subject: RE: What to do for 'change' type events in Event subclasses (emulation) Funny, I see it too in our app, but this works <?xml version="1.0" encoding="utf-8"?> <s:Application xmlns:fx="https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fns.adobe.com%2Fmxml%2F2009&data=04%7C01%7Caharui%40adobe.com%7C35f1cfa87a4f4a5806d708d8a4e1c2b7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637440636830868592%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NoC2PH%2FJZLdxxSyXAVinexS%2FmTGcYtKXKlak3rwUFLc%3D&reserved=0"; xmlns:s="library://ns.apache.org/royale/spark" creationComplete="init()" > <fx:Script> <![CDATA[ import components.MyComp; import mx.collections.ArrayList; private function init():void { var dp:ArrayList = new ArrayList(['one', 'two', 'three']); myList.dataProvider = dp; } private function changeHandler():void { trace("here i am"); } ]]> </fx:Script> <s:List id="myList" width="100%" height="100%" change="changeHandler()"/> </s:Application> From: Greg Dove<mailto:[email protected]> Sent: Sunday, December 13, 2020 5:40 AM To: Apache Royale Development<mailto:[email protected]> Subject: What to do for 'change' type events in Event subclasses (emulation) Events that have 'change' string type do not appear to work as advertised in SparkRoyale (and perhaps in MX as well, although I am only eyes-on with Spark at the moment). Because 'change' is treated specially at the level of ElementWrapper, it gets swapped for a browser 'change' event. This seems to be avoidable simply by renaming to event name in the subclass to avoid the conflict. e.g. IndexChangeEvent monkey patch: public static const CHANGE:String = 'indexChange'; //was 'change' and also, for example, in DropDownListController: //added IndexChangeEvent var ice:IndexChangeEvent = new IndexChangeEvent(IndexChangeEvent.CHANGE, false,false,selectionModel.selectedIndex, popUpModel.selectedIndex ); selectionModel.selectedIndex = popUpModel.selectedIndex; //was : dispatch the generic 'change' event IEventDispatcher(_strand).dispatchEvent(new Event("change")); //also now: dispatch the IndexChangeEveht (monkey patch IndexChangeEvent.CHANGE) IEventDispatcher(_strand).dispatchEvent(ice); Above is quick and dirty... and seems to work for now where needed. But is there a way to do this correctly (similar to Keyboard and Mouse conversions) so that 'change' event names don't need to be renamed? Obviously it affects mxml event completion also which is normally typed to the subclass for the 'change' event name, so it is not necessarily desirable simply to change the const values because then all the mxml that is based on the original value needs to be changed also. Does anyone else have an approach that addresses this issue more generally? Would appreciate any thoughts/insight.... thanks, Greg
