What is an expressive way of looking for patterns of events over time, and triggering new events?
For example, user interface events are often built up patterns of simpler events, such as mousedown/up, mousemove, or keyup/keydown.
A drag and drop interaction requires listening for a mousedown event, followed by a number of mousemove events, followed by a mouseup, and looking for if draggable/droppable UI objects are targeted by the different events. Additionally, you might want to have a timing and distance threshold to avoid triggering a drag when the user might have tried to click, and you might want to look for modifier keys, or escape to cancel the interaction.
Dealing with these things as number of individual event listeners quickly gets complex and error prone, tricky to debug, and often leads to conflicts between different events.
What abstractions are common for expressing these patterns succinctly and clearly?
The Composite pattern jumps to mind as a way to structure the code, because you have primitive events which combine to form complex events, while all events conform to a basic interface.
For a behavioral pattern, we intuitively think of an event as being observable; but in the case of a composite event, we may think of it as an Observer as well, where a complex event observes one or more primitive events.
Related
I've got this in my html file:
<textarea id="inputbox" placeholder="type here"></textarea>
What's the correct way to wire up a handler that will fire immediately whenever the content of the textarea changes? (whether by keyboard, mouse/clipboard, speech input, brainwave reader, etc)
I tried:
query("#inputbox").on.change.add(handler)
but (at least on Dartium) it only fires after you tab out of the field.
The purpose is to update a "live preview" window, similar to the way Stackoverflow renders Markdown output while you type.
This is the best I came up with so far. I'd be happy to hear if anyone knows of a more compact or preferable alternative.
Edit: Code snippet updated to the new pattern for event registration.
import 'dart:html';
void main() {
query("#inputbox")
..onChange.listen(handler)
..onKeyDown.listen(handler)
..onKeyUp.listen(handler)
..onCut.listen(handler)
..onPaste.listen(handler);
}
void handler(Event event) {
print((query("#inputbox") as TextAreaElement).value);
}
The precise behavior will vary between browsers and operating systems.
You could skip keyDown, but be aware keyDown and keyUp behavior is influenced by the OS and isn't guaranteed to be symmetric. You might conceivably miss a change, at least until the next keyUp or change event gets fired. Indeed I proved this out by creating a little app on Windows 7 to send an orphan WM_KEYDOWN message to Dartium and IE9.
keyPress could be used instead of keyUp and keyDown, but won't generate events for certain keys like backspace and delete.
cut and paste react immediately to a cut or paste performed with the mouse. If you don't use them, the change event will capture the change, but not until after the field loses focus, or sometimes even later.
The input event could replace all listeners above and seems to work great in Dartium, but under IE9 it only captures character additions, not removals.
Note keyUp and keyDown may generate additional unwanted events for cursor keys, home, end, shift, etc. (e.g. In IE9). It will fire in addition to the cut/paste listeners when the user uses shortcut keys for those actions.
While the question is specific to Dart, a lot of the discussion above applies to any code listening to the DOM. Even keyCode values aren't standardized across browsers (more detail).
It may also be worthwhile checking out the KeyboardEventController class, though by and large when I tested it the edge case behavior was similar to that noted above. That may or may not be by design. The Dart developers do make some effort to insulate you from cross-browser inconsistencies, but it's still a work in progress.
Also while we're talking about textarea, remember to use its value property, not its text property. Finally, be sure your handler throttles its reactions to "bursts" of keyboard activity (e.g. some sort of timer that briefly defers the guts of your handler and rolls up any additional events which occur in the meantime).
Related questions and links:
Handle events in DART
Handling Keyboard events in Dart Language
How do you listen for a keyUp event in Dart?
Cross browser key event handler in Dart
jQuery example that skips keyboard events and binds to propertychange
Its not clear if you are using polymer or not, but if you are, you can subscribe to a change to a variable annotated with #observable by creating a function in the polymer element in the form as [variable name]Changed(oldvalue). I originally found this here: How to subscribe to change of an observable field
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)
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 written a few relatively trivial GUIs in WxWidgets and Qt, and I'm persistently unsure how to architecturally handle the following situations:
You catch a mouse event to do something to a graphical object in your GUI
What you do with the object depends on which modifier keys the user is holding down
At the start I usually do something like the following:
void MyClass::mouseMoveEvent(QGraphicsSceneMouseEvent* event)
{
if (event->modifiers() & Qt::AltModifier) {
// do something
} else if (event->modifiers() & Qt::ControlModifier) {
// do something else
} else {
// do yet another thing
}
}
// Repreat ad-nausium for other mouse click/move events...
Eventually, with similar if/else/switch code in lots of mousePressEvent, mouseReleaseEvent handlers, this seems a bit unwieldy so I try and encapsulate some of the repetition by putting the object into different "modes" depending on which modifiers are down. Nonetheless, I still feel I'm missing some nice elegant solution.
I've tried to look at the code of various open-source tools but I've not found anything tangible (erm, simple) enough to point me in a different direction.
Some tools (say, the GIMP) seem to have so many rich and varied tool- and modifier-dependent behaviours that I feel there's got to be a nice way of architecting this pattern.
Event handling in such a GUI toolkits decides what to do according to an event and an event handler you provide. What you need is a way to decide what to do according to an event, modifier and an event handler. So you can based on your events and modifier call special event processing object in all of your standard event handlers for events provided by the toolkit. What you have to implement is that event processing object, which will according to an even and modifier call the right behaviour (event+modifier handler). This is what I would call Chain of responsibility design pattern.
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.