You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Greg Dove <gr...@gmail.com> on 2020/12/13 03:40:31 UTC
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
Re: What to do for 'change' type events in Event subclasses
(emulation)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <yi...@hotmail.com> 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<ma...@hotmail.com>
Sent: Friday, December 18, 2020 3:30 PM
To: dev@royale.apache.org<ma...@royale.apache.org>
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<ma...@gmail.com>
Sent: Sunday, December 13, 2020 5:40 AM
To: Apache Royale Development<ma...@royale.apache.org>
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
RE: What to do for 'change' type events in Event subclasses
(emulation)
Posted by Yishay Weiss <yi...@hotmail.com>.
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<ma...@hotmail.com>
Sent: Friday, December 18, 2020 3:30 PM
To: dev@royale.apache.org<ma...@royale.apache.org>
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="http://ns.adobe.com/mxml/2009"
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<ma...@gmail.com>
Sent: Sunday, December 13, 2020 5:40 AM
To: Apache Royale Development<ma...@royale.apache.org>
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
RE: What to do for 'change' type events in Event subclasses
(emulation)
Posted by Yishay Weiss <yi...@hotmail.com>.
Funny, I see it too in our app, but this works
<?xml version="1.0" encoding="utf-8"?>
<s:Application
xmlns:fx="http://ns.adobe.com/mxml/2009"
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<ma...@gmail.com>
Sent: Sunday, December 13, 2020 5:40 AM
To: Apache Royale Development<ma...@royale.apache.org>
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