Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Adobe AIR Development

Reply
Developer
Posts: 193
Registered: ‎12-29-2010
My Device: Bold 9900
My Carrier: Rogers

MouseEvent.CLICK vs Event.SELECT

Hi,

 

I just caught myself using MouseEvent.CLICK  and Event.SELECT interchangeably.

 

I realized that I was writing the MouseEvent in the listener, and just "Event" in the dispatcher. Does it make a difference really.

 

For example I wrote:

 

backgroundPopUp.addEventListener(Event.SELECT, backgroundPopUpSelection); 

 

 

private function backgroundPopUpSelection(e:MouseEvent):void{

 

// Do something

 

}

 

In other cases I've also switched around the MouseEvent and Event.

Does the "Event" encompass every type of event, including MouseEvent?

 

While that combination does seem to work, I don't wan't it to do something unexpected. Any recommendations? Also, what would you stick to? Just Events? or Mouse Events?

 

I'm thinking of changing everything to MouseEvent to be consistent. What do you think?

 

Thanks!

Developer
Posts: 1,008
Registered: ‎12-12-2010
My Device: Passport (Red Limited Edition)
My Carrier: Mobile Vikings

Re: MouseEvent.CLICK vs Event.SELECT

Consistency is advisable in code, so try to be consistent.

 

I don't really know the exact differences, my guess it that Event.SELECT is less likely to be widely supported in the Playbook SDK. It is a more general approach to selecting an item, whereas MouseEvent.Click specifies a more exact event. I would advise to use MouseEvent since it is closer to the user actually touching the screen, more defined and is more likely to be supported by the final SDK.

-------------------------------------------
BlackBerry Certified Builder for Native Application Development -- Proud member of the Belgian BlackBerry Developer group
Samples: Park in Ghent
Feeling generous? Nominate me for BB Elite member!
Developer
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: MouseEvent.CLICK vs Event.SELECT


gpatton wrote:

I realized that I was writing the MouseEvent in the listener, and just "Event" in the dispatcher. Does it make a difference really.

 

For example I wrote:

 

backgroundPopUp.addEventListener(Event.SELECT, backgroundPopUpSelection); 

private function backgroundPopUpSelection(e:MouseEvent):void {...}

 

In other cases I've also switched around the MouseEvent and Event.

Does the "Event" encompass every type of event, including MouseEvent?


This is basically a question about object-oriented programming.  MouseEvent subclasses Event, so "Event encompasses" it only to the extent that a parent class "encompasses" a child class, which is to say not really at all (though see my last paragraph for more on that).

 

What you've written "works" only, I suspect, because you are not actually using any MouseEvent-specific properties in the handler.  If you were to do that, I'm not entirely sure what will happen but I think you'd get an exception because of an undefined/null property.  (I'd be more clear on this if I were expert at ActionScript, but my knowledge in this area comes from C++, Python, and Javascript and I won't entirely trust that experience here.)

 

What you could do is reverse those: e.g. if listening for a MouseEvent.CLICK, specify it as just "e:Event" in your handler.  In that case, although the object that is actually delivered is really a MouseEvent, you're accessing it using a reference that believes it's just an Event.  You'd have to do "e as MouseEvent" (effectively a cast operation) inside the listener to get access to the MouseEvent-specific properties in that case, but it would be totally proper to do it that way if you intended only to access generic Event properties.  (But as @zezke says, consistency is generally desirable.)


Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!
Developer
Posts: 2,462
Registered: ‎11-04-2010
My Device: Bold 9700

Re: MouseEvent.CLICK vs Event.SELECT

hey gpatton,

 

different objects in AS3 dispatch different events. some dispatch MouseEvents whereas others dispatch only Events. Like the others have stated the reason why you are able to use the MouseEvent in the listener is because you are using a more "advanced" class then of the Event class. so the compiler will not throw a coercian error because MouseEvent extends the Event class and has all of its basic functionality. What you are doing is "up casting". if you were doing it the other way around (down casting) it may throw and error and its usually not as safe as up casting.

 

when i code i stick to the event that best describes the action the user is ultimately doing. it keeps things organized and understandable. Yes the user is clicking on the menu item but he/she is really selecting an option.

 

on a side note though there are some objects that dispatch very specific events such as the list objects in the QNX docs. they do not dispatch the normal Event.SELECT event but the ListEvent.ITEM_CLICKED. the reason why you should listen to the the ListEvent specific event is because when an event id dispatched the ListEvent also sends data that is specific to the List object to the user instead of a plain event.

 

hope that helps. good luck!

J. Rab (Blog) (Twitter)
--
1. If you liked my post or found it useful please click on the thumbs up and provide a Like!
2. If my post solved your problem please click on the Accept as Solution button. Much appreciated!

Approved Apps: OnTrack | ssShots | Hangman
Developer
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: MouseEvent.CLICK vs Event.SELECT

 


JRab wrote: 

What you are doing is "up casting". if you were doing it the other way around (down casting) it may throw and error and its usually not as safe as up casting. 


 

Actually if the object dispatched is an Event but he receives it as "e:MouseEvent" it's effectively downcasting.  If he receives a MouseEvent but references it with "e:Event" then it's upcasting.   "Up" refers to going up the class hierarchy, so casting a child class to a parent (or higher-level ancestor) is up-casting.  Taking an Event object e and doing "e as MouseEvent" is downcasting.

 

I said "effectively" above because I don't think what's actually happening is technically a typecast operation, since there's no explicit use of the "as" operator for the "downcasting" case.  It actually looks like a bit of a loophole in the language if a mere Event can be sent but you can say that it's a "MouseEvent" in the handler's argument list.  I'm curious what part of the language specification is actually allowing that to happen without an error either at runtime or (assuming "strict" mode) at compilation.


Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!
Developer
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: MouseEvent.CLICK vs Event.SELECT

@JRab, my apologies if you were trying to say the same thing as I was... I just realized when you said he was doing "up casting" you might have been referring not to the example shown, but to his second case where he said "in other cases I've also switched around the MouseEvent and Event" (i.e. where it really was up, not down).


Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!
Highlighted
Developer
Posts: 2,462
Registered: ‎11-04-2010
My Device: Bold 9700

Re: MouseEvent.CLICK vs Event.SELECT

hey peter,

 

no need to apologize. your post is spot on with my mistake. although my explanation about up and down casting is correct its out of context. when it comes to receiving events and handling them i dont know if it cares about what you "cast" the event as because as you stated it may not be doing any of that. From what i understood objects in AS3 dispatch not just one event but a number of them depending on what the user is doing. although they are "selecting" an item and an Event.SELECT is dispatched, its not the only event dispatched. A mouse click can also be dispatched along with it. so when you listen for the the MouseEvent.CLICK event you are listening for the event string "click". and coincidently it is available along with the "select" string being dispatched by the target.

 

im going to re-read my event handling material on AS3 and get back to you guys cause now its bugging me haha... gpatton you can revoke my kudo. Smiley Indifferent

 

to be continued.

J. Rab (Blog) (Twitter)
--
1. If you liked my post or found it useful please click on the thumbs up and provide a Like!
2. If my post solved your problem please click on the Accept as Solution button. Much appreciated!

Approved Apps: OnTrack | ssShots | Hangman
Developer
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: MouseEvent.CLICK vs Event.SELECT

 


JRab wrote:

From what i understood objects in AS3 dispatch not just one event but a number of them depending on what the user is doing. although they are "selecting" an item and an Event.SELECT is dispatched, its not the only event dispatched. A mouse click can also be dispatched along with it. so when you listen for the the MouseEvent.CLICK event you are listening for the event string "click". and coincidently it is available along with the "select" string being dispatched by the target.


 

That's right.  The string (e.g. "click" in the case of MouseEvent.CLICK) is basically used as an address or "topic" for the subscription.  What is delivered to all subscribers for that topic is an actual instance of the MouseEvent class (i.e. an object), which is a subclass of the parent Event class.  I suspect it's confusing to some people when they use MouseEvent.CLICK, possibly not realizing it is merely a way of saying "click" that lets the compiler catch typos, where if you typed "clikc" it could not.

 

And as you say, for certain user actions more than one event can be triggered.  The canonical example is probably the basic mouse click, where you get a down-event delivered on the target object, and an up event delivered later, possibly on some other object.  In between you may get a bunch of move events as the mouse is moved, and others. 

 

If, and only if, the up event is seen on the same object that originally saw the down event, then you will also get a click event (I think that's an accurate description), so the act of releasing the mouse button may deliver two separate MouseEvent objects.  Usually, though, you will be interested in only one of them.


Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!