I was noticing on certain application for wp7, that they were able to use the enter key on the keyboard to submit, but by default when you hit the enter key it goes to the next line. I was even noticing the enter key is different from the default enter key.
How do you submit, and if possible how do you change the way the enter key looks?
Any tips, answers or resources would be appreciated. Thanks.
You need to change the InputScope from "Text" and then capture the enter key on the KeyDown event.
As Matt states, the keyboard layout depends on the InputScope that you specify. You can find some illustrations of the different layouts on Jeff Blankenburg's blog.
If you're interested in using the Enter key to "tab" between input fields, there's a great behavior you can use.
Correct me if I'm wrong, but it seems more standard (on a touch device) to trigger a submit/enter on the up/release. One benefit being, if you press on an adjacent key to the one intended, you can then drag over to it and release.
Related
Hoping this is an easy question that I'm just overlooking something...
I want to submit my logon form when a user hits enter from within a passwordbox. Is there a way to do this without capturing keystrokes & determine when enter is being hit?
Thx
Scott
Silverlight doesn't support AcceptButton property/behavior that WinForms has. You'll have to manage the KeyDown event, looking for an Enter key. There's nothing wrong with that, if you wanted the password you could just look at the text property in the text box. Your program has full access to the password, so shying away from a KeyDown event seems kind of frivolous. Monitoring the KeyDown event is a legitimate way to get things done in your code.
I'm developing an application with the official WPF Ribbon system, and I'd like to have a password field up in the ribbon. Is there any way I can modify the RibbonTextBox control to display dots instead of characters, the way a PasswordBox does? Thanks in advance.
Can't you just use the key up event, and take the value out of the box, store it in a variable, and replace it with the character you want?
User presses "A" on key up, you grab the value, store it in a variable, and then replace it with an "*". Keep doing this until they stop typing in the box?
The WPF text box responds to quite a number of editing commands. I want to eliminate the vast majority and have it respond to any text input and few editing commands like backspace & delete. I know I can handle the KeyDown event but I can't see any easy way of distinguishing between character input and editing key strokes.
You can use the Preview events. They happen before the actual key events that actually perform the work. For instance, if you want to disable the down arrow for moving up and down in text, in the PreviewKeyDownEvent you would check 'e.Key' for the down key, and if found, and set e.Handled = true. This effectively removes that key press from the processing. As such, KeyDown will never get called.
Using this method you can remove specific keys, or combinations of keys and modifiers (such as CTRL-C if you wanted to disable the 'copy' shortcut).
Hope this helps! If so, don't forget to vote it up and/or mark it as accepted.
WPF does not have a built-in masked text box under .NET 3.5.
You will find lots of starting places if you search google and stackoverflow for: WPF Masked TextBox
I'm developing a large line of business app with C# and WPF. Our standard is to include accelerator keys for buttons on all forms (Save, Cancel, Search, etc.). I've recently noticed that when a form is loaded, the accelerator key is active even when the user does not press the "Alt" key. For example, our Search button uses "Alt-H" as the accelerator, but the user can initiate a search by simply pressing "H". I'm using the standard "_" in the button content to create the accelerator key.
<Button Content="Searc_h"/>
Has anyone else noticed this behavior and has anyone found a suitable workaround that requires the "Alt" key to be pressed?
This is standard behaviour for accelerator keys on Windows whenever no text input is focused. Please don’t break it, just leave it in.
You can check this yourself. Press Win+R to bring up the "Run..." dialog, then Tab so one of the buttons is focused, then press "B". The "Browse" button will get activated.
This is also why you can answer those MessageBox prompts with a simple Y/N (instead of Alt+Y / Alt+N).
Don't put the underscore in at all, then add this to the window.
<Window.InputBindings>
<KeyBinding Command="Help" Key="H" Modifiers="Alt"/>
</Window.InputBindings>
Menu and ToolBar mnemonics work without pressing Alt key in WPF. This is the microsoft standard.
Refer the this link http://social.msdn.microsoft.com/Forums/en/wpf/thread/14f6f49f-0027-471b-b68c-e7f6ba012012
This article on Sara Ford's Weblog discusses this phenomenon.
A commenter mentions this as a solution:
"If you're writing an application and you don't like this behavior, look up WM_CHANGEUISTATE and specifically the UISF_HIDEFOCUS flag."
Actually, the Command pattern in WPF allows you more granular control over what keyboard shortcuts are allowed. It goes a step further than the "_" in your button text.
Check the following link for more information:
http://www.switchonthecode.com/tutorials/wpf-tutorial-command-bindings-and-custom-commands
Edit: previous link was dead - provided a new link.
-Doug
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).