When the user clicks left CTRL+ left SHIFT I want to make the entire application translucent (like VS2008's intellisense drop-down). If I write my code on the KeyUp event I can capture both keys being pressed, but the transparency effect should only be active while the keys are pressed. When they are release the opacity should go back to 100%. The behavior I want is actually the KeyDown event, but I can't capture both keys on KeyDown, can I?
Thanks
Use the static methods of the Keyboard class, specifically IsKeyDown() to check the state of the keys you're interested in.
On KeyDown you can use this to enable the translucency and on KeyUp you can disable the effect again. If you are at it, you could save the key's state yourself and act upon it.
Related
As I am trying to make my own custom "WinForms", I am left confused on when does each mouse event occurs. I have made my own custom classes, but now the events are something I have to rework, as they won't work right.
I have a custom class for controls. Objects from that class can contain other controls, which can contain other controls and so on. There is a main control, which gets input from a picture box. That input is what is where the mouse is and what even has been activated in the picture box.
So far I have figured, that MouseMove, MouseHover and MouseDown events are the simplest to write, as they occur in simple conditions. But the rest require additional data about the mouse's location, state and past. MouseDoubleClick seems to activate after a specific sequence of events (strictly down-up-down-up, down-up-down-move-up and down-up-down-move-leave-enter-move-up, with the movement events not activating). With that in mind, I am even more confused.
In what conditions and sequences does each mouse event occur?
EDIT
Further testing made things even more confusing. For one, now I want to know at what rate is the MouseMove being registered, and testing it shows that between each event there is a different time (or so does my use of a StopWatch say). This is important, because then that raises the question when is Hover being triggered.
Click is down-up, where moving is allowed between the two.
DoubleClick proved to be simple enough - down-up-down-up, where moving is allowed explicitly only between the second down-up.
Hover activates only once after each Enter, when the mouse remains stationary; if you want to trigger Hover again, the mouse has to leave and then re-enter.
So the question now is how the system tracks the mouse's activity - how does it detect the mouse moving, being held down and being released. Hopefully that would help me get the full answer.
Is there a way in WPF to get active touch points? I need to determine if user is touching screen, similar to Mouse classes' Pressed -property?
I just need to know if any touch is present on the screen - don't mind what UIElement it's touching.
Here are two options, but they may not be the most correct way to do it:
1) You could subscribe to the MainWindow.PreviewTouchDown and MainWindow.PreviewTouchUp and maintain a list of all the current touch devices. It would be easy to implement but could make your code messy.
2) Subscribe to Touch.FrameReported which you can get a collection of touch points from the TouchFrameEventArgs.GetTouchPoints(null);. This will happen on every touch event firing, so it may be too often, but it would allow you to handle this event from any class.
You can subscribe to your main windows ManipulationStarting event (when the first finger makes contact with the screen), ManipulationInertiaStarting event (when the last finger lifts off the screen) and/or ManipulationDelta event (when any finger moves).
Within your event handlers you can get a list of all current touchpoints via ManipulationDeltaEventArgs.Manipulators
Don't forget to set your main window's IsManipulationEnabled to true.
This way you just have to remember whether a manipulation is currently in progress or not. You don't have to keep track of all the individual touch points yourself.
I want to detect when a combination like Ctrl-C is pressed in a WPF application. What I've read online says to use something like the following in the KeyDown (or KeyUp) Event:
if ((Keyboard.Modifiers == ModifierKeys.Control) && (e.Key == Key.S))
{
MessageBox.Show("Save!");
}
I'm just trying to understand how this works. As I understand it, e.Key contains the key that was pressed that triggered the event and Keyboard.Modifiers contains the information about the state of the Control key right now. Is it safe to assume that the Control key will still be down by the time the KeyDown event gets handled?
For example, I restart Firefox and it grinds away loading a bunch of tabs, and in the meantime I hit Ctrl-S in my application. There is a delay in getting to KeyDown, and the application thinks just S has been pressed.
Thanks
You could use KeyBindings instead, they define full gestures without such a separation.
I have been using WPF with all the tunneling and bubbling events and I must say they are simply great and powerful.
But what I always question myself is whether to use the [PreviewKeyUp and KeyUp] or [PreviewKeyDown and Keydown]?
Which combination should I be using to react to key presses and why?
Depends on what you want to do:
PreviewKeyDown = BEFORE the key is pressed
Example: If you have the event on a textbox the current key pressed is not added to the TextBox.Text
PreviewKeyUp = BEFORE the key is let go
KeyDown = AFTER the key is pressed
Example: If you have the event on a textbox the current key pressed is added to the TextBox.Text
KeyUp = AFTER the key is let go
So again it depends on what you want to do. If you want to add TextBox validation use PreviewKeyDown to ignore the text if its incorrect. If you want to do something when the user let go of SPACE then us KeyUp
It all depends upon the situation, for example, selecting an item in a list will want to be KeyDown so that the key can be held and the selected item changed.
If you have an element with multiple visual states, e.g. a button, the KeyDown may change the visual state, then the KeyUp will return the visual to the original state and execute the command.
In your situation it will all depend upon when you want the event to be raised, I wouldn't say either one was better than the other as they are for different uses.
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).