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
Related
I tried to type a question mark into the tooptip text box of a control in the properties panel, and suddenly I got switched into code view. It turns out shift + / (or ?) now seems to be bound to a command I've never heard of which navigates to the next event handler that's referenced in XAML. So now I can't type question marks since the shortcut seems to be global.
I'd like to be able to figure out how to change this behavior, but the search bar in the keyboard options only seems to search for commands and not for shortcuts. How do I find what command is being triggered and why?
In the keyboard options dialog, press a shortcut in the Press shortcut keys box. Shortcut currently used by list will show all currently assigned commands for this shortcut:
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.
I am looking for an embeddable interactive console. I want the user to be able to type in some custom commands, and the application to write command responses in it. Would be awesome if it would understand powershell or python, ans supports command completion.
I already built my own bash-like terminal, but I do not want to totally reinvent the wheel, so I'm looking for a third-party stable component before going any further with it.
If someone is interested, I found PoshConsole, a powershell console:
http://poshconsole.codeplex.com/
Thanks
PS: you can find a screen of what I am trying to achieve here:
http://www.hiboox.fr/go/images-100/codein,0a2809b63e05c3d0cac678962e0e3d5a.jpg.html
Nothing found since I asked the question, and to stick with the "do it yourself" way of thinking:
I wrote a terminal-like control in .NET.
http://wpfterminal.codeplex.com/
You can see an example in this screenshot (terminal is integrated in a bigger project) :
http://images4.hiboox.com/images/4210/0a2809b63e05c3d0cac678962e0e3d5a.jpg
Basic mechanisms
Actually what I did was to define a lastPromptIndex integer, and everytime a user presses the ENTER key and a new prompt appears, this value is updated.
After that, it's simple, you just need to process any text input before the textbox validates the input. If the textbox caret was located before your lastPromptIndex, you need to raise an error (usually a beep sound) and you must invalidate the text input, so nothing is written in the textbox. I also automatically set the caret position to the end of the textbox, so the user can immediatly input some text.
Extensions
You can enable command completion by looking for an "UP key" input if the caret is before the prompt index, etc. What you need is just to process input events before they are sent to the textbox internal mechanisms. I don't know if SWT controls allow it, but I'm pretty sure they do, like any serious UI system.
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 have a wpf application (I use CAL) for a tablet pc.
I created a custom text input panel.
Now is my question: How can I disable the default TextInputPanel?
This is only through my application offcourse because I still want the utility in my winxp and other apps on the tablet.
The problem is that when I hover to long near a textbox, the small tooltip to open a TextInputPanel always appears and I want to suppress that!
Kind regards,
Wim
Already posted at WPF Forums but with no result :s
http://social.msdn.microsoft.com/Forums/en-US/tabletandtouch/thread/835b910d-e357-4bd8-b26a-f99e7d549b3f
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/c5bd3b90-c731-4e5b-a812-ee29490800e3
Disabling the Input Panel UI
Setting the DisableInPlace registry key to zero prevents the Input Panel user interface (UI) from appearing in an application. You must place the DisableInPlace registry key at HKLM\Software\Microsoft\TabletTip. Then, add a new registry value by using the full path of the application in which you want to disable Input Panel. The following example registry entry disables Input Panel in an application called MyApp:
[HKEY_LOCAL_MACHINE
\SOFTWARE\Microsoft\TabletTIP\DisableInPlace]
"C:\Progam Files\My App\MyApp.exe"="1"
(Finally) Found this info here: http://msdn.microsoft.com/en-us/library/ms812266.aspx
I don't like it that much (reg. editing) but at least it's a solution ;)
Kind regards,
Wim