I've just the documentation on the Qt event system and the QEvent class. I'm interested in the behavior of the QObject::event() method. The documentation states:
This virtual function receives events to an object and should return true if the event e was recognized and processed.
What is the expected behavior when false is returned from the event() method? What else is attempted in order to handle the event? Is the event automatically forwarded to the parent object?
Note: I know the source is available, and I do have a copy. I'm ideally looking for some piece of documentation addressing this behavior.
I believe the best practice is to explicitly forward the events to the base-class event method if you do not wish to filter that event type (e.g. return QObject::event(event);) since the event function delegates events to specific handlers (e.g. QWidget::keyPressEvent).
QCoreApplication::notify propogates events based on the return value. On true, it considers the event as consumed and stops. Otherwise, the event is passed to the object's parent. For more information, see Events and Filters and Another Look at Events.
Some Events can be propagated.Event will be propagated to it's parent and it's parent recursively until it is processed. Take a look at this:https://doc.qt.io/archives/qq/qq11-events.html
Related
I'm implementing a module using nesC for TinyOS. My modules uses interface Timer<> so I have to implement the event fired of the interface Timer, it is possible to return a value inside this implementation or an event must be always void?
The return type of the Timer.fired event is defined as void and this cannot be changed. Even if the type was non-void, the returned value would be delivered to the component that signals the event, which is some system component implementing the Timer interface.
In order to get some hints on how to solve your problem, please provide more details explaining for what purpose you want to return a value from the fired event, that is, who is expected to get and process the returned value.
I have an httpservice object instantiated and have defined an event listener to handle the result.
e.g.
http.addEventListener(ResultEvent.RESULT,function (event:ResultEvent):void {
// handle result
// ...
//should I remove this anonymous event listener?:
event.currentTarget.removeEventListener(event.type, arguments.callee);
});
I'm only curious from an efficiency/best practice point of view.
Depends if you're going to reuse it, and/or if you need closure variables from the current scope. If there's no reuse, then data-hiding might suggest making it local or at least private. If it's something that's going to be reused, or something that might even be overridden by a subclass, then make it separate and protected.
My 2 cents.
Update:
Whoops, I thought the question was whether the listener should be anonymous or not.
You should definitely remove any listener, anonymous or not, if it's no longer needed. Otherwise, it's useless cpu usage if the event keeps firing.
How can I tell what the default behavior for a cancelable event is?
For example, I read somewhere that the TextEvent.TEXT_INPUT has a default behavior and that default behavior includes adding a text character associated with the key that was pressed to a TextInput. That makes perfect sense.
But if I hadn't read that, how would I know what the default behavior is? Other than guessing. In this case, it's probably obvious. But in other situations, it might not be.
For example, in the docs, look at DataGridEvent.HEADER_RELEASE's cancelable property. It says:
cancelable: true
so, there appears to be a "default behavior" associated with a DataGridEvent.HEADER_RELEASE event. But what is it? And why would I cancel it if I'm not really sure what it is? :)
thanks.
It's all in the documentation, which says: "The DataGrid control has a default handler for this event that implements a single-column sort."
The live docs a pretty thorough. If you keep following the links you'll usually find what you are looking for.
Here's what I think to be true -
To cancel the default behavior associated with an event, 2 things must be true:
The event must be marked as cancelable (you can check the event's cancelable property to determine this). If you are dispatching the event yourself, set the 3rd parameter to true to mark the event as cancelable. If the event is marked as cancelable, calling event.preventDefault() will set the event to "cancelled" and a query of event.isDefaultPrevented() will return true. If the event is NOT marked as cancelable, calling event.preventDefault() will do nothing at all. A query of event.isDefaultPrevented() will always return false no matter how many times you call event.preventDefault().
The event handler registered for the event must actually have the ability to do nothing (i.e. prevent the default behavior associated with the event). So the handler must have something like this in it:
if (!event.isDefaultPrevented()) { doSomething(); }
So, that still leaves me with the question - "For a cancelable event of type X, what is the default behavior?"
I guess that depends on the target of the event. For example, the target of a DataGridEvent.HEADER_RELEASE event is a DataGrid and inside the DataGrid class you'll find this in the constructor:
addEventListener(DataGridEvent.HEADER_RELEASE,
headerReleaseHandler,
false, EventPriority.DEFAULT_HANDLER);
and the handler looks like this:
private function headerReleaseHandler(event:DataGridEvent):void
{
if (!event.isDefaultPrevented())
{
manualSort = true;
sortByColumn(event.columnIndex);
manualSort = false;
}
}
Or, you can poke around aimlessly in the docs forever and maybe stumble on the answer like this:
http://livedocs.adobe.com/flex/3/langref/mx/controls/DataGrid.html#event%3aheaderRelease
"The DataGrid control has a default handler for this event that implements a single-column sort"
Hopefully, this answer helps reduce the aimlessness of your doc search.
Jeremy
I have ItemRenderers that need to listen for events. When they hear an event (and when data changes), they dispatch an event with their current data value.
As item renderers are reused, each of them is going to add its callback in set data(value...)and pass the callback function in the event as well as the current data value.
So, the listener of the item renderer's bubbling event will set someEventDispatcher.addEventListener("someEvent", itemRendererEvent.callbackListener). This will happen more than once.
Does setting the same event listener on the same event for the same dispatcher waste resources? Does the displatcher see that it already has the listener?
I believe other than the initial call to add the listener, it doesn't waste resources.
However it's a good idea not to add any listeners unnecessarily, and it's also a good idea to keep any sort of business logic out of getter / setters, but that's strictly for the sake of code legibility.
There's a few questions on stack overflow on this topic but I'm still unclear:
I know the flash engine is single threaded so when it receives an event, does it essentially break off, execute any registered event listeners (in no guaranteed order) then return to the current scope?
If I have this code:
addListener("stuff", function():void {
// some stuff
});
addListener("stuff", someFunc);
dispatch(new Event("stuff"));
trace("Done.");
I want to know:
Can I guarantee that both listeners have executed by the time I reach the trace("Done"); line?
edit:
or
can I guarantee that the current function will complete before any of the event listeners execute? ie trace("Done"); will ALWAYS execute first.
or
Neither.
It is guaranteed that both event handlers will be called before trace because user code generated events are synchronous:
Does dispatching an event interrupt a function?
From what I know, when you dispatch an event it gets added to the event queue, but won't actually run until the currently-executing event finishes. In other words, you'll trace "Done.", then your function ends, control passes back to the event handler, and only then does it (maybe) start executing one of your events.
Yes, you can guarantee both assertions in this exact situation.
Meaning, that if adding your event listeners and dispatching your event is in the same code block it will happen in sequence. However, from a practical POV that's completely useless.
#kryoko: player events get precedence over user events, but they do not 'force' themselves through. Meaning that if user code is running, the player event handling is suspended. That's why it's possible to 'freeze' a flash movie with heavy, intensive code. (Or with a simple infinite loop, of course)