ok, in part of my AS3 lurnings, I've come to the realization that it's best to just write a custom event for every damned little piece of interaction. But I've also gotten to the point where I've ended up writing duplicate functions for events that I want to trigger in different ways.
Eg.
I want to go to load a MovieClip on the click of a button.
function loadIt(e:MouseEvent){ addChild(MC); } btn.addEventListener(MouseEvent.CLICK, loadIt);
Great. First of all utilizing events for simple things is over kill. But here's where I'm stuck.....
Is there ANY possible way I can trigger this from the timeline now? loadit();
Nope. I get errors because it's looking for the event to be passed and it's data. So, I end up duplicating functions which is what OOPing was supposed to avoid.
Where am I going wrong on my understanding of this all?
can you not just pass it a dummy MouseEvent, loadIt(new MouseEvent()); ? Since you're not using any of the MouseEvent data in your loadIt function, it doesn't matter what it is. A bit scruffy perhaps, but what the hey.
Another alternative is to do it like this:
function loadIt(){ addChild(MC); }
function handleClick(e:MouseEvent){ loadIt(); } btn.addEventListener(MouseEvent.CLICK, handleClick);
Then you can call the func loadIt() from anywhere without any dummy params.
BTW you're not writing Custom Events here - this is just an event handler.
I'm off to bed now. I look forward to reading your rant on how crappy all this is in the morning 
Idiot. How's that?
Yes, I know I'm not writing custom events in this example. It was all part of my 'expected' rant when I deal with AS3. It tires my brain. It's gotten to the point where I'm writing custom events for everything because I want to pass a variable from the clicked Object to the receiver which makes the most sense to me instead of triggering the event and then having the listener use the target.data to 'read' the variable. But what can I say programmers and how they think have never made sense to me.
So, on to this....I never thought of an empty MouseEvent. Clever thought process. I'll go with that.
Your second example illustrates what I'm trying to avoid.......multiple function writing to accomplish ONE GOAL......do something. I really like the democratic simplicity of production in Flash before where MCs were allowed to talk to each other. This totalitarian production method "ah comrade, you must use the Party's Comrade Messaging Event System" before we can allow that information through.
We're all comrades now.
СпаÑибо за Вашего товарища помощи. (Thanks for your help comrade.)
Since you're not using any of the MouseEvent data in your loadIt function, it doesn't matter what it is. A bit scruffy perhaps, but what the hey. I like it. That accomplishes my goal. Scruffy? Who gives a shit.
function loadIt( e:MouseEvent = null ) { addChild(MC); }
btn.addEventListener(MouseEvent.CLICK, loadIt);
// loadIt(); will now also work
sweet muther of pearl
thanks lith
yeah, Lith's is even better 
Personally though I always go with the two function solution you hate Storm The reason being that for me there are two distinct functions here - one is the event handler, and the other is the method doing whatever it does. I usually call my event handlers something like handleHelpButtonClick, so reading that method name it wouldn't make sense to try calling it in any other way.
I disagree with using default values in parameter definitions based on who's calling it. The function is now syntacticly forever tied to a mouse event it should never have been aware of. Fancy, maybe.
Wait until the function is moved into a class a year from now and the sport who has to throw it in a package has to go hunt down the anonymous mouse event that was triggering it, or the coder will just write the function deer in the headlights style and simply wonder why a mouse event has to be the only parameter. No offense Lith, it's a perfectly acceptable answer, but DBM's solution is more manageable code.
Gawd, I sound like barn.
disregard this entire post at will.
You're salty today persist.
And in lith's defence, I don't think that is what lith would do. He was nicely answering my question.
[removed by persist]
yeah, that has a nice ring to it.
I know that I'll never truly be able to get my point across to the programmers here, but you guys have to understand at some point that we think pretty much completely the opposite to you. I know you don't understand what that means but just because something is "right for code" doesn't make it "right for a project." And so having one function encapsulate the process and be able to be referenced by anybody is a good thing in how us designers approach a project because when the client changes their mind, we know exactly where it is instead of "was it the function that called that other function or was it just that function?"
completely different thought processes
It's ok for the right answer for this situation to be something that you would never do and your feedback is good. But not exploring all options isn't fair either. We want choices. That's why we got into Flash at version 2.....the ability to do something different and the way we felt was best. It has always been a flexible program.
not everyone likes caviar, sometimes peanut butter is just fine.
I imagine Storm's code here is just going into one FLA that's going to do one job and never get worked on again, so in this case it doesn't really matter how manageable the code is, as long as Storm can understand it.
I suppose that's good if you're into creating a self limiting box.
I guess i don't operate under the guise of "I am only doing x."
And just cause I know how to code doesn't make me different or not understand. I am a designer before I am a coder.
srsly, check out my javascript question in front end. I am using a timer to solve an event problem. I can't think of any other way to solve that issue other than an ugly closure/inheritance hack.
In this case there's a few ways and the one with the least amount of actual typing happens to be the best. I don't know why you wouldn't choose it, other than it's ok cause no one will ever see it. I don't know what a specific project has to do with keeping a default mouse event out of a public function. That isn't some nerdy oop construct. It's common sense. Last time I checked, common sense applied to every profession.
I thought lith's was the least typing is all.
Common sense is applied. But objectives are different. Code in one place for a single person development team is always easier to find than code spread across multiple classes all using inheritance. Common sense is defined by objective. This shit doesn't get used again nor should it try to.
still luv yur salty ways....DBM give him a hug
[thread removed by persist]
//this code works on the timeline, you may need to scope traceIt with a 'this' or local var pointing to this.
btn.addEventListener( MouseEvent.CLICK, function( e:MouseEvent ){ traceIt() } );
When an event is fired I often don't want information passed in the event, I think it is better not to assume what information the listener wants as mostly it doesn't want what you have on offer, I prefer to ask for the information on receiving the event. I have not checked the code below but sort of explains what I mean, I realize there are downsides, but it is easy to end up with really complex custom events, and that sort of goes against encapsulation because you are passing around complex information that is never used. You could look at using a NativeSignal in my example below but seems simplest to me to mix them like this.
class Fred {
public var clickedSignal: Signal = new Signal(); private var _mc: MovieClip;
public function get mcX() {
return _mc.mouseX;
}
public Fred( mc_: MovieClip ) {
mc = mc; mc_.addEventListener( MouseEvent.CLICK, function( e: MouseEvent ){ clickedSignal.dispatch(); } }
}
}
// so could be used in another class... _fred = new Fred( an_mc ); _fred.clickedSignal.add( mcClick );
private function mcClick() {
trace( _fred.mcX );
}
My example isn't necessarily the way i would do it, but it is a solution. However I'll occasionally use that method when the MouseEvent is irrelevant. i.e not using evt.currentTarget in the body of the event handler.
shrugs
JLM - what's all that Signal stuff about? Never heard of it, is it some extension of/alternative to EventDispatcher?
DontBogartMe
Using EventDispatcher ties you to inheriting EventDispatcher or Sprite, and as you may have gathered I often prefer more of a composite approach especially since large inheritance chains are generally not good for porting code to other languages. In some languages there is the concept of slots or signals Robert Penner has again revolutionized flash by starting a Signal's approach.. Signals are really nice I find mixing them as above works quite well.
You can get Signals from..http://github.com/robertpenner/as3-signals
Watch a video its really easy to use...http://johnlindquist.com/2010/01/21/as3-signals-tutorial/
The haXe version you can use for different targets here is a flash haXe example of using HSL ( it just loads in some images ), and like I say I use the limited passing no arguments approach, but you can do loads more in HSL if you want.http://www.justinfront.net/haXeImageExample/imageLoadExample.zip
( Have to agree with Lithium, his suggestion is a handy solution, and often a good quick fix ).
that looks interesting, thanks for the hidden gem JLM