Is there a way to disable auto-repeated key events? Specifically I'm using the closure google tv web ui library, and when holding down/up scrolling through the components of a tv-container-vertical I'd like it to only move one at a time, regardless of whether the key is pressed or held.
The short answer is that it's not trivial to do. You will need to define the key behavior with your own handler which would override the GTV provided closure lib code for key navigation.
Related
I have an InfiniteContainer list where each element is a relatively complex container with several different buttons with each their action. Since it's a scrollable list, I use LongPointerPress to activate drag and drop like Shai recommended in another post. To do this I need to set a lead component to handle this. However, when I set it, none of the other buttons get their individual events. I thought I could overwrite the getLeadComponent() of the buttons to have it return null, to ensure those buttons handle their own events, but it's private and haven't been able to think of any other solution for now.
Is there a recommended approach for handling this?
NB. I've been spending a LOT of time piecing together partial advice from different posts, and using trial and error to get this UI to work. It would be useful if the CN1 documentation could contain more explicit advice on the approaches that work for such 'real life' complex UI which combine eg lists, drag&drop, multiple buttons, long press for additional actions, Swipable containers, ... It shouldn't feel like constant hacking ;-)
You can setLeadComponent(null) when you are done with the lead component functionality to "undo" the lead component effect. The lead component behavior is an "all or nothing" approach.
If this doesn't work for you you can override the low level events in the Form and implement the functionality there. You can block components from getting events by not calling super.pointer* methods in Form and thus allow any sort of effect.
Imagine a karaoke player / keyframe animation system / etc. written in qooxdoo. A Player object will have a property to reflect current position. The property will be bound to some GUI control, say slider, so that the user can jump to an arbitrary position. In the same time, position will be gradually updated by the playback mechanism when playing.
The problem is, different logic should be applied in these two cases.
1) If the "position" property is set from outside (for example, the user has clicked a slider), some complex logic applies: we should recompute active verse/line/syllable/pair of keyframes (possibly using binary search) and activate it;
2) If the property has been updated by an iteration of playback mechanism, the logic is very simple: we should only check if the boundary of the next object has been crossed, and advance to it.
In both cases the standard logic (instance check and firing change event) should be invoked. I've been thinking about either bypassing complex "apply" method by setting $$user_position variable directly, or analyzing current call stack and taking different paths depending on that, but both methods seem to be dirty hacks. That's why I'll be thankful for any recommendations on how to implement the said in qooxdoo the Right™ Way®.
I think a common pattern for such a situation is not to burden the property itself with too much functionality (meaning: its apply method). Rather, keep the property rather simple and use it just to record the current position. Then devise methods like 'goto' and 'next' that both update the position property, albeit with different algorithms, as you wrote.
My AutoCompleteBox calls a WCF service when the selection is changed, usually with the mouse. However if the user uses the arrow keys to navigate through the selection, the event fires up for each element, making the application too much data intensive.
How do I prevent the AutoCompleteBox_SelectionChanged to fire when the keys are pressed?
I found this which sounded like a nice solution but it doesn't work http://betaforums.silverlight.net/forums/p/137710/307786.aspx
ok, rather than using AutoCompleteBox_SelectionChanged, I'm using AutoCompleteBox_DropDownClosed, and this fixed the problem.
I just found how I have solved this same problem. Also I am not using SelectionChanged.
I added behavior to item DataTemplate (to Grid root). This behavior attach click handler to item. When keys are used, behavior is "sleeping", when I click on item with mouse, behavior get called and make its work. (Also I bind needed property of item to a DataTemplate's Grid's Tag property, so I can get to it from behavior)
Not suitable for every solution, but can be useful.
I need to respond to keydown events (O, C, G keys etc., not modifier keys) while a Drag+Drop operation is in progress over my control (i.e. between DragEnter and DragLeave). However the KeyDown event is not called at this stage.
I've tried selecting my control and specifically setting focus on DragEnter, but that doesn't work.
EDIT:
Hans' answer is basically correct, except I had to use GetAsynchKeyState to get the behaviour I wanted.
The QueryContinueDrag event is raised on the drag source. Checking for the state of the keys you are interested in is going to require pinvoke, the event is only designed to help recognize the Escape key and modifier key state changes. Which is something to keep in mind, that these keys have any special action is very undiscoverable.
[DllImport("user32.dll")]
private static extern short GetKeyState(Keys key);
It returns a value < 0 when the key is down. I can't say it's guaranteed to work correctly but it looked good when I tried it.
You can also try:
Keyboard.IsKeyDown(); method to check if a specific key is pressed, i.e.:
bool isKeyPressed = Keyboard.IsKeyDown(Key.LeftAlt);
It's similar to the previous answer, but it's a native .NET method, so it doesn't require you to import any functions.
A similar question has been asked here: Handle KeyDown during a drag drop. Or keydown event not workign, but there was a suggestion to make it work like an event.
UPDATE
The first solution seems to work only in WPF. If you want to check states of modifier keys, there is, however, a method utilizing a property Form.ModifierKeys that should work correctly in WinForms. The example shows how to check if alt (left alt) and ctrl keys are both pressed:
if (Form.ModifierKeys == (Keys.Alt | Keys.Control))
{
//TODO: insert your code here
}
This is a subjective question, but I need opinions.
I have a WinForms C# application whose window hides itself after a specific keystroke (Enter or Escape), with possible modifiers (e.g. Ctrl-Enter). When hiding on KeyDown or KeyPress, the other application that becomes active after my window hides itself receives the KeyUp event for that keystroke. Normally, it shouldn't affect that other application, but some of them out there react on KeyUp. For example, TweetDeck sends the message currently being edited on "Enter" KeyUp, even if it did not receive KeyDown/KeyPress.
So I thought, fine, I'll be a good citizen, I'll hide on KeyUp. But this doesn't feel right. If I only look for keys up, I'm doing what I blame others of doing! If I try to create an history of matching KeyDown/KeyUp, I'm over-complicating my code (modifiers generate their own key up).
What should I do? What should a well-implemented application do?
This is a hack, but you can set the state of your program to "pending hide" when receive the key down. And then when you get the key up for that sequence, reset the "pending state" and then hide.
Alternatively, can you just "eat" the key up off the message queue after you receive the key down?
I would not worry too much about applications handling key up rather than key down - like you point out - the only reason this is an issue is because your app changes active windows in the middle of a key down key up sequence. It is your responsibility (IMO) to also "eat" the key up messages. You can probably just handle the key up instead of key down with no adverse side effects.
EDIT
Thinking about this further - when doing alt-tab to go to a new window - the action does not happen until the key up. In the meantime it shows a window of possible apps to change to. You can do similar action and the behavior has a precedent.
So:
On key down: Display window that indicates app will hide.
on key up: hide window
This is "stateful" - you can only go into hiding if you received the key down and the key up - at least that is what I would do. 99.9999% (guess) not handling key down would be ok.
I can't think of any program that implements keyboard shortcuts on the KeyUp event. That standard was set a long time ago, with the Windows TranslateAccelerator() API function. It translates WM_KEYDOWN. Windows Forms implements the same behavior with ProcessCmdKey().
Sounds like you found a doozy. Does it handle Alt+F4 correctly?
Well, I'd say "Don't worry about it, until it becomes a problem", but I guess it is a problem now....
In that case, I would hide on KeyPress (the expected user experience), but grab the focus until you get a KeyUp (or until a short timeout).