Re: [Flashcoders] Calling Listener Functions

2008-04-06 Thread Muzak
] To: Flash Coders List flashcoders@chattyfig.figleaf.com Sent: Sunday, April 06, 2008 5:06 AM Subject: Re: [Flashcoders] Calling Listener Functions I disagree with this approach. It's unnecessary and makes code less manageable. It's cleaner to set the argument as optional (event = null) than write

Re: [Flashcoders] Calling Listener Functions

2008-04-06 Thread Matt S.
True. But then again, if at the start you already find yourself needing to call a function outside of the context of a mouse event, doesnt that indicate that locking it in as such, and then finding workarounds, might be more trouble than its worth? 2ยข .m On Sat, Apr 5, 2008 at 11:06 PM,

Re: [Flashcoders] Calling Listener Functions

2008-04-06 Thread Omar Fouad
mm, well guys, when it comes to a long function that handles an event, It wouldn't be convenient to REWRITE it another time to be used manually. Anyways, I'll give a try on that, and feedback. Cheers and thanks for the help. On Sun, Apr 6, 2008 at 2:11 PM, Matt S. [EMAIL PROTECTED] wrote:

[Flashcoders] Calling Listener Functions

2008-04-05 Thread Omar Fouad
Hi, I've got a function that is called when a listener listens an event like: fancyButton.addEventListener(MouseEvent.CLICK, myFunction); private function myFunction(e:MouseEvent):void { // statements... } If I try to call myFunction using myFunction() , the compiler throws me an error,

Re: [Flashcoders] Calling Listener Functions

2008-04-05 Thread Matt S.
On Sat, Apr 5, 2008 at 8:58 PM, Omar Fouad [EMAIL PROTECTED] wrote: Hi, I've got a function that is called when a listener listens an event like: fancyButton.addEventListener(MouseEvent.CLICK, myFunction); private function myFunction(e:MouseEvent):void { // statements... } If I

Re: [Flashcoders] Calling Listener Functions

2008-04-05 Thread jonathan howe
Technically speaking, you can instantiate a bogus MouseEvent to call the function: myFunction(new MouseEvent(MouseEvent.CLICK)); However, I only mention this to be complete in directly answering the question. I would think that Matt's suggestion is the more appropriate. -jonathan On Sat, Apr

Re: [Flashcoders] Calling Listener Functions

2008-04-05 Thread Muzak
the handler into 2 methods, and call the 2nd method directly when needed. - Original Message - From: Omar Fouad [EMAIL PROTECTED] To: Flash Coders List flashcoders@chattyfig.figleaf.com Sent: Sunday, April 06, 2008 2:58 AM Subject: [Flashcoders] Calling Listener Functions Hi, I've got

Re: [Flashcoders] Calling Listener Functions

2008-04-05 Thread Rich Shupe
Oops. I forgot to include a link to post about this. Here it is: http://www.learningactionscript3.com/2007/11/21/mandatory-argument-types/ On 4/5/08 8:58 PM, Omar Fouad wrote: Hi, I've got a function that is called when a listener listens an event like:

Re: [Flashcoders] Calling Listener Functions

2008-04-05 Thread Rich Shupe
You can also just send null. myFunction(null); On 4/5/08 9:38 PM, jonathan howe wrote: Technically speaking, you can instantiate a bogus MouseEvent to call the function: myFunction(new MouseEvent(MouseEvent.CLICK)); However, I only mention this to be complete in directly answering the

Re: [Flashcoders] Calling Listener Functions

2008-04-05 Thread Steven Sacks
If you're not actually accessing any of the properties of the MouseEvent in your listener function, you could do the following: (...args) or you could keep it strict and use (e:MouseEvent = null) Either works fine, though the second one is explicitly cleaner. Omar Fouad wrote: Hi, I've

Re: [Flashcoders] Calling Listener Functions

2008-04-05 Thread Steven Sacks
I disagree with this approach. It's unnecessary and makes code less manageable. It's cleaner to set the argument as optional (event = null) than write another subroutine. Matt S. wrote: You might want to separate the functions, so you would have myFunction(), which you could call from

Re: [Flashcoders] Calling Listener Functions

2008-04-05 Thread Rich Shupe
I agree. I can see both sides of the point--more granular encapsulation, etc. However, in addition to creating more breadcrumbs to follow, it may not be all that practical in every case. You may not always know you need this and may have to deal with less manageable code more and more as the need