Develop Reference

CoreWindow.KeyDown doesn't get called if Enter is pressed with focus on clickable element

Is there any way I can still catch the keypress if Enter is pressed on a clickable element.
Because the Windows Store Apps API treats Enter as click event rather than a keypress if the focus is on a clickable element (i.e. a GridViewItem).
Unfortunately I have to let the user right-click on a GridViewItem which sets the focus to the element.
Moving the focus would be an option but I'd prefer not to do that if I don't have to.

It seems, this is not in the nature of WInrt. You can follow the specification provided on MSDN:
https://msdn.microsoft.com/en-us/library/windows/apps/windows.ui.xaml.uielement.keydown.aspx
You can still try the Key Down event of GridView

In WinRT, some events are user-initiated only. As a result, some WinRT APIs can only be invoked in those types of events. Button.Click is one of those events. As a result, you cannot programmatically raise this event because it would undermine the security feature that limits certain API to those types of events.
Make sense?
Best of luck!

Keydown event not firing in user control obj

I have a user control which is not declared in the designer. I have a button that I want to have create this user control when I click it - it should initialize the user control and insert it in the main UI.
However, it happens that the user control has a key press event on it, which is not firing.
Why does this happen?
I already tried to attach the event on the user control itself but it seems that it's not firing at all. Is there some kind of bug?

It is very hard to fix problems with code that you can't see, but in WPF, there are often reasons why Bubbling events like the KeyDown event don't fire. Occasionally certain controls may make use of these events and set them as handled internally, thereby stopping them from bubbling up any further.
The normal solution on these occasions is to use the related Tunneling events instead, which are raised before the Bubbling methods and not used internally by controls. So, while I can't guarantee that this will fix your problem, it is certainly worth trying to handle the UIElement.PreviewKeyUp event instead of the UIElement.KeyUp event.

Getting events when Button object is released

On Windows 7 Phone, using Silverlight framework
I'd like to handle when a Button is released.
It's easy to tell when the button is pressed (Click event which is fired either when pressed or when released according to the ClickMode property)
I've played with all the other events provided with the Events editor (KeyUp, LostFocus, MouseLeave etc..)
But I'm yet to find something that is definitive in regards to getting an event when a button is released.
Ultimately, I'm trying to handle doing a click vs a long click when pressing on a button
Thanks

For your situation, KeyUp is only half of the story. You also need to handle KeyDown where you will save the current time which you will then compare to the current time value after KeyUp to determine whether the press was short or long. You also need to make sure that you track one particular key in case your handler(s) is/are intercepting all key strokes.
If for some reason ClickDown/Up don't work out you could try handling the Click event but starting with a ClickMode of press, then changing ClickMode to release on the press handler. This process, though not simple, would give you a chance to implement the down-hold and timer-release sequence that you're looking for.

Keydown event when the form is not active

How can I capture the Keydown event of a form that is not active?
I found references to ProcessKeyDown but I couldn't find any help on that.

Please set KeyPreview of the form to true. First select form and press f4 key, it will open property window and their is KeyPreview and set it to true.

Right cilck on the form and cilck properties, then there will be flash button , it is for events for that object. Find thier Keypress event. just doulbe click on the column corresponding to that event. It will create event for keypress.
For the documentation and help, check this link.

Keypress events are only sent to Controls that have input focus. You can use the Control.HasFocus property to determine whether your Control has focus or not. Use the Control.Focus() method to give your control focus.

You can set a low level keyboard hook using SetWindowsHookEx() to listen for key press events.

If what you want to do is trigger some code in your program upon keys being pressed in the operating system regarding of whether the form is active or not then you can use the method described in this article:
Processing Global Mouse and Keyboard Hooks in C#
Here is a simple example of a program using that library to simulate a virtual mouse by pressing the numeric keys on the numpad.
'1'-'4' and '6'-'9' are directional keys, '5' is left click, '0' is double click.
Program.cs
Form1.cs
Observe that i didn't call the Application.Run(); with a new Form1() parameter so that the application would run but will not be visible on screen. To end the program you have to press CTRL+SHIFT+ESC, go to Processes page and end the process manually.

Global PreviewKeyDown handler vs local PreviewKeyDown handler

I have a PreviewKeyDown handler on my mainwindow which handles up and down keys so I can navigate with the keyboard between my controls.
Now I have the problem that in some Textboxes I also want to use the up/down keys. This seems impossible because the other handler seems to swallow the keys first.
Is it possible that when one of these TextBox controls are focused they get the up/down keys first and then then swallow them so that the "global" PreviewKeyDown does not get them?
Sure I could disable the global handler somehow when such a TextBox got focus but is this good style?

You don't really have an option, aside from filtering out those keys in the global key handler.
The reason that you're having this problem is that all of the Preview* events are tunneling, meaning that controls higher in the visual tree get them first (starting at the root). The very reason why you're using this event in the first place is causing your problem.
One less than ideal option would be to register a class handler for TextBox.PreviewKeyDown (see EventManager.RegisterClassHandler()). While this would be called before your window's PreviewKeyDown handler, it will be called for all TextBoxes in your application. This may or not be what you want.