It is said in the docs, that EventDispatcher's dispatchEvent "...dispatches an event into the event flow". The phrase is nice-looking and doesn't really explain anything.
Say, we have two listeners waiting for an event "A" on object "a", so what behaviour do we have to expect on calling:
a.dispatchEvent("A")?
Would both listeners be called immediately, before return from distpatchEvent? Or they will be queued in some internal flash player queue and will be processed by entering the next frame? Can we rely on some defined behaviour of flash player here or the behaviour is undefined? How one should read "dispatches an event to event flow"? The question is important since in practice it affects the control flow of the code.
It all depends on your display list hierarchy.
Flash's event structure is based on its internal event model.
The Stage will be the first object
notified, and then the event will
trickle down the display list until
it reaches its target. This phase is
called the capture phase. To enable it, set useCapture to
true on an event listener. Do note
that it's pointless to do so unless
the object listening is a parent of
the object targeting the event. This
is called event intercepting.
The next phase is the target
phase. This is the behavior most
commonly known with events. The
targeted display object (the one the
has a listener for the event) will
receive the event and carry out the
code in the listener.
The final phase is called the
bubbling phase. This is when the event bubbles up the display list
after the event has been received. Event bubbling is very important for
dispatching custom events, as you'll
need to know how to listen for
events dispatched by an object's
children.
When dispatching an event, I generally use this syntax (Event.CHANGE is just a common example):
Object.dispatchEvent(new Event("CHANGE", true, false));
The Object is the object you're dispatching from. The first parameter is the event you're dispatching. The second is the bubbles parameter. The final is the cancelable property. Event.cancelable is used to prevent the default action of an event (IE: a mouse click) via Event.preventDefault().
Reference:
Chapter 21 of Colin Moock's
Essential Actionscript 3.0
EventDispatcher.dispatchEvent()
Event.cancelable
Just use Signals instead :P
https://github.com/robertpenner/as3-signals/wiki
No but really, they're very easy to use and understand, a great addition to the AS3 toolbox.
You can also learn a lot about how native AS3 events work by reading Rob Penner's critiques (scroll down to bottom of wiki page)
Related
Is it possible (e.g. by overwriting a prototype) to filter (enable/disable) events globally in KONVA?
use case:
I have an interactive app built with KONVA. At the beginning, I want to show a "demonstration" of the user interface: I'm displaying a moving second mouse cursor and fire events which are handled by the app to demonstrate possible interactions. All is working, but during the demonstration, the app should not listen to real mouse events, only to the simulated ones (having a special property set in event object).
For that use case, just set listening: false for your stage. It will disable ALL events on the stage and its children.
You can turn off events just for demonstration. As soon as it is done, you can turn mouse/touch/pointers events on with listening: true.
I am trying to run some code upon cancellation of an AppointmentItem, however two of the events that I tried to capture fire more than once (Application.Send, AppointmentItem.Write, BeforeDelete doesn't fire). This bring me to re-think my logic and find a suitable place to implement it. I couldn't find a reason why the two events are fired twice in my case as I am using inspector wrapper to register these events on a new inspector window and Un-registering them on inspector close event.
Please note that I want to monitor all possible scenario where an Appointment can be canceled/deleted.
Why do you even need any inspector events? Monitor the Application.ItemSend event, check if you get a MeetingItem object as an argument, check that the message class is "IPM.Schedule.Meeting.Resp.Neg" or Class = 55 (OlObjectClass.olMeetingResponseNegative).
I have developed an extension for Safari which uses a context menu.
In the code, I am listening to the command event of the context menu item using:
safari.application.addEventListener("command", commandHandler, false);
In the commandHandler() function, I have added an alert statement for debugging purposes. By doing so, I found that the function commandHandler() is firing twice whenever I click on the context menu item.
Also I added a tool bar item, which also fires the command() event on clicking. The function attached to the command() event is also firing twice after clicking on the item.
Does anybody know of this issue and how to resolve it?
Without more information, this sounds like a problem of insufficient filtering. That is, you're receiving all command messages without determining which they are or why they're flowing across your callback layer, and your callback layer receives two messages per click of, as given, unknown disposition.
The event notification callback structure for Safari extensions allows you to register multiple events against the same event type, and multiple distinct events may be generated in many cases. To this end, your attempt to add an event listener to the "command" scope means you're literally receiving all commands passed to the callback layer. These may be multi-firing in cases where you have, for example, a complex nesting relationship (A contains B, where A and B both notify) or a complex behavior pattern (for example, a mousedown followed by a mouseup).
Apple provides guidance on how to handle this scenario, by binding the command to a specific target or specific command, which is what you should do here. And just in case that's insufficient, here's additional documentation on how the callback system works to help you define your events properly.
Following the guidance should allow you to work through this issue by properly binding your events to your object and only operating on the events you need. Everything else should simply be ignored by your event handler.
This may be a basic question, but I have to admit I've never truly understood what the difference between the Control.Enter and Control.GotFocus events is.
http://msdn.microsoft.com/en-us/library/system.windows.forms.control.enter.aspx
http://msdn.microsoft.com/en-us/library/system.windows.forms.control.gotfocus.aspx
Is it a differentiation between capturing keyboard or mouse input or something else?
The GotFocus/LostFocus events are generated by Windows messages, WM_SETFOCUS and WM_KILLFOCUS respectively. They are a bit troublesome, especially WM_KILLFOCUS which is prone to deadlock. The logic inside Windows Forms that handles the validation logic (Validating event for example) can override focus changes. In other words, the focus actually changed but then the validation code moved it back. The logical state of your UI is that it never moved and you shouldn't be aware that it did.
The Enter/Leave events avoid the kind of trouble these low-level focus change notification events can cause, they are generated when Winforms has established the true focus. You almost always want to use these.
Control.Enter event happens when a control gets focus for the first time. While Control.GotFocus happens EVERY time a control gets focus. For example, you have 'textBox1' that already has focus and you call textBox1.Focus(), the GotFocus event will always fire in this instance, unlike for the Enter event that will only fire if a control doesn't already have the focus and receives it for the first time.
I've heard of events and SO answers "bubbling up", but what has all that got to do with bubbles?
Event bubbling is the idea of information moving up through a deep structure, when proper design dictates that normally information should only flow downward.
In very basic terms, think of a single object. Properly designed, this object should only know about its own child objects. It should have no direct interaction with its parent. Its children and parent objects, in turn, should follow the same rules. In effect, this means that information can only flow downward - a parent can invoke a method, send data into or extract data from its child, but the child cannot forcibly do the same to its parent.
Think of what happens when you blow an air bubble underwater - you don't have to push the air towards the surface - you simply release it and it moves on its own. The same concept applies to event bubbling - deeper controls simply "release" their information - usually via an event - and it "floats" up the chain without directly invoking anything.
With regard to a website like Stackoverflow (or practically any kind of site), the concept of bubbling is the same. Obviously each individual post ought not directly put itself on the home page, but when a single post has been updated, that event is released from the deepest point in the hierarchy - a single post - and floats up to eventually the top level, where it is dealt with (choosing whether or not to display on the home page).
If you are asking about the term, I guess it is an analogy to an event 'bubbling' up to the top, like an air bubble does in liquid.
If you are asking what event bubbling is it is an event that is caught by one object that will refire it to any other objects that are listening to it.
To quote a good article here
... a technique called event bubbling
that allows a child control to
propagate events up its containment
hierarchy. Event bubbling enables
events to be raised from a more
convenient location in the controls
hierarchy and allows event handlers to
be attached to the original control as
well as to the control that exposes
the bubbled event.