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.
Related
There is a TextChanged event for the RichTextBox, what I require is a TextChanging event so I have chance to perform an action before the text is changed. The KeyDown event is not enough as my application uses a speech recognition engine which means it is possible to enter text without using the keyboard.
I was hoping I could intercept something in the WndProc method but nothing stands out.
Any ideas or help would be much appreciated. Thanks.
Try using the TextChanged Event from the RichTextBox class. Based on the description from MSDN
This event is raised if the Text property is changed by either a programmatic modification or user interaction.
It should be able to handle what you are trying to do.
Edit: You could have some sort of intermediary storage of the text so that when the text changes it is stored somewhere else first and after the text changed event is done, you can put the text back into the RichTextBox. But without knowing specifically what you are trying to accomplish, this would be my recommendation.
I'm creating a WPF application and I need to do something when I get some user input (it may be keyboard, mouse, ...) my question is if WPF have a generic event that tells me if the user have entered some input or do I have to handle all the events (MouseMove, KeyDown, TouchDown, ...)
Check InputManager.PreProcessInput/PostProcessInput.
I have an application in which there are lot of TextBoxes and some Buttons like Save, SaveAs,etc.
When the user edits a TextBox, I have to check the DataBase for some range, validate the range and update the DataBase.
If there is any error in value entered by user,then I should not allow the TextBox to lose focus.
I was using LostFocus event for this and it was working fine until lately I discovered a bug in my application.
Bug : The user edits a value in TextBox and then clicks on Save button; the LostFocus event is not called and so Database is not getting updated :(
Now my question is which event should I use in TextBox to update the DataBase. I tried TextChanged event but it validates for every character and making my application slow. I am confused in chosing the right event for this kind of application!
Note :** The Buttons are in different UserControl !
EDIT 1 : I have some Commands attached to click of Buttons, these Commands are getting executed before LostFocus !! Can I set precedence or something like attached behaviours or commands should get executed after LostFocus !!
EDIT 2 : I was just debugging the application by disabling some commands, what I found was in some cases, the DelegateCommand gets executed before LostFocus, so I want to avoid that. How can I go about it ? I felt during development its impossible to developa pure MVVM application so I am kind of using a bit of codebehind !
Trapping the keyboard focus within a control is usually a sign of bad UI design - it's pretty user-hostile to force the user to fix data in a control before he can type anywhere else in the UI.
That said, you shouldn't be using events at all here. You're trying to write a Windows Forms application in WPF. You should write a WPF application.
Create a class that is a logical model of your view - i.e., there's a string property for the text box and a Command property (or, more likely, a RelayCommand) for the Save button. Bind the text box to the string property, e.g.:
<TextBox Text="{Binding MyTextProperty, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}"/>
Because the UpdateSourceTrigger is PropertyChanged, the source object will get updated every time the user types a character.
Bind the button to the command property, e.g.:
<Button CommandBinding="{Binding SaveCommand}">Save</Button>
Implement the appropriate CanSave and Save methods that the RelayCommand (as described in Josh Smith's essential article on the MVVM pattern) requires, so that the button is enabled when the string property is valid and disabled when it's not.
I think the best approach is preventing a user to proceed until all valid information has been gathered.
Just like an installation wizard with Terms & Conditions Dialog and Next button. Until you check the I Agree checkbox, Next button is disabled.
This way, you don't have to worry about user proceeding without providing valid information. This way, you can use any event on TextBox to validate your data.
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.
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).