I've hooked up some basic click events using Meteor's event maps.
How do I stop the event from propagating after being handled?
Meteor's docs state that
Right now, the event handlers are wired up with jQuery, and the event
object you receive is a jQuery event object.
However, neither return false nor e.stopPropagation() seem to work.
Currently, stopPropagation works in a limited set of circumstances. For propagation to stop between two handlers, the handlers must be specified on different templates, and there has to be an intervening DOM node container between the inner and outer template. A fix is under development right now and will go into an upcoming release.
Can you post a gist of your code so I can make sure your particular case will be addresed?
As a workaround, you might try e.stopImmediatePropagation(), which is supplied by jQuery and should keep any other handlers from running.
I ran across this question while researching this myself. The documentation for Blaze Event Maps is here.
For this problem in meteor you need to consider 2 functions depending upon what you want:
stopPropagation()
Prevent the event from propagating (bubbling) up to other elements. Other event handlers matching the same element are still fired, in this and other event maps.
stopImmediatePropagation()
Prevent all additional event handlers from being run on this event, including other handlers in this event map, handlers reached by bubbling, and handlers in other event maps.
What I wanted was to stop bubbling and stop propagating to other Meteor event handlers. So event.stopImmediatePropagation() did the trick and it is not really a workaround as advised above.
Related
I am trying to figure out when and how .queued in DreamFactory is fired.
From DreamFactory article,
https://blog.dreamfactory.com/queueing-with-dreamfactory-scripting/
there are 3 events that can be fired after running GET to resource, e.g.:
api/v2/db/_table/<table_name>.get
I understand when Pre-Process event and Post-Process event are fired. But I just can't figure out when .Queued is fired.
As DF is using Laravel in the framework, may be someone can share some idea about how this works.
Starting with release 2.3.0, queued scripts, on the other hand, do not and cannot affect the processing of the original API call. Both the request and response of the event are saved along with the script and queued for later execution. Queued scripts are primarily useful for triggering other workflows that need to be done when an event happens, but not necessarily during the processing of the event.
The queued event, when fired, will save the following into a job that is queued for later processing…
the script identifier
the full request and response of the event
a snapshot of the environment at the time of the API call
Kindly refer to the following references for a better picture
https://blog.dreamfactory.com/queueing-with-dreamfactory-scripting/
http://wiki.dreamfactory.com/DreamFactory/Features/Scripting/Event_Scripting#Queued
Thanks
I can not seem to get the a TimedMetadataTrack object to fire the events CueEntered or CueExited for SpeechCue events.
Any thoughts?
So, apparently this line is needed when registering for IMediaCue.CueEntered and IMedia.CueExited events (at least the SpeechCue implementation of the interface):
((Windows.Media.Playback.MediaPlaybackItem)item).TimedMetadataTracks.SetPresentationMode((uint)index, Windows.Media.Playback.TimedMetadataTrackPresentationMode.ApplicationPresented);
This line is required to exactly allow the system to send the CueEntered and CueExited events that are being listened for.
Yet again, another case of Microsoft not fully documenting things in their API Documentation or Code Examples.
Is it possible to have a WH_KEYBOARD_LL hook that only calls the hook function when my application/thread has the focus? Currently I'm receiving calls even when the application is not active.
Sure, the 4th argument to SetWindowsHookEx() can be a thread ID to make it selective. Pass the one for your UI thread, get it by calling GetCurrentThreadId().
Do note that this is not normally very useful, you can intercept keyboard messages in your message loop just as easily. Every GUI class library supports this, required to implement shortcut keystrokes. Even the winapi has this, TranslateAccelerator(). Strongly recommended, debugging a hook is very painful since a breakpoint in the hook callback or any function called by your callback will cause the keyboard to seize up for 5 seconds and your hook to be destroyed.
There's no way for you to install a hook and also apply some form of filter to suppress it firing in certain states. Once it is installed, it will fire.
So, either do nothing in your hook function when your application is inactive, or remove the hook when it becomes inactive. Or, do away with the hook altogether, and respond to the messages that arrive in your message queue.
I'm trying to do the following - given an keypress event in an QT Application, I want to intercept it, modify it (for instance, replacing Qt::Key_Up with 0x81001310), and send it into the app again.
Ideas?
Does overriding the event method work? If you do get all of the keypresses there, just consume the events you wish to replace and send new events that you want.
Might not work, just an idea that should be easy to test.
Be careful to not cause infinite recursions or loops :)
Edit:
If this doesn't work, you can always create an eventFilter and modify the events that way. However, if you do this, you might have to install the event filter for many things.
I'm not a solid GUI programmer, so I'm trying to understand different event architectures. I'm developing a system (in GWT, but I'm not sure that matters) where we are introducing a few custom events. In general, is it good practice to create an event and have the event fire itself onto to the event bus?
Following some articles and tutorials online, we have our controller code actually firing the events, but then each controller has to duplicate the code to fire the custom event. It seems that if you just put a fire() method on the event itself you can avoid that duplication.
What are the pros/cons of doing this?
In order to have an event fire itself, you'd need to inject the EventBus instance into the event when you create it. This means your controller (the one newing up the event) would have:
new MyEvent(m_eventBus).fire();
If you rework the code like this:
MyEvent event = new MyEvent();
m_eventBus.fireEvent(event);
then you wouldn't have to put any logic or references to services inside your Event instance, where it's not really needed. If you're using GWT, the HandlerManager class already implements an event bus for you.