CommandManager.InvalidateRequerySuggested() is called automatically every time a key has been pressed, when the focus has changed etc. I'd like to prevent this from happening under certain conditions (for example only call it when keys pressed are not Up or Down) and do my own handling of RoutedCommands, because InvalidateRequerySuggested() always processes all commands and is a bit slow.
I can see in the reference source where InvalidateRequerySuggested is called, but I don't see a way to intervene there. There is a PreProcessInput event, but the necessary information you'd need from it is hidden in internal classes like InputReportEventArgs.
Is there a way?
Related
I'm listening to FrameworkElement.KeyDown events and am trying to catch [Ctrl][Shift][0].
This must be some "special" combination in some ways, because the event fires for every combination of these three keys, but, if I press [Ctrl], then [Shift] (in either order) and then [0] (=Key.D0) the event fires for the first two keys, but not for the last one, when all of them are pressed together.
I found this, and it mentions something about WM_INPUTLANGCHANGEREQUEST, but I don't understand what that is (nothing happens on my system when I press the combination); and the proposed solution there doesn't help me, because it doesn't apply to a FrameworkElement - and I need it in the KeyDown handler ...if possible.
Currently, I'm settling for [Shift]+[0]... :o/
I have few buttons in my windows application which has mnemonics.Now if i press multiple keys the events of the button clicks gets fired as i have used mnemonics.
But the behaviour is not as expected,because second button event handler is getting executed before the first button event handler has finished its execution,and also i have written my code in such a way that in the event handler of first button i am disabling my second button,still the second button event handler is getting executed.The problem here is due to mnemonics.PLease suggest me a better way to handle mnemonics as soon as possible.
Thanks in advance.
If your logic is tied to your buttons, change that. Let your buttons merely manipulations an object that implements your logic. You can then check in this object whether the requested action is allowed (i.e. whether the previous operation has finished.
Alternatively you can just disable buttons when running and re-enable then when.finished.
I'm trying to implement some sort of solution to the 'double submit' problem that occurs when there is a submit button that fires a code routine that takes some time to run.
Unfortunately, with a good number of users still using old internet browsers and some running no-script addons. I cannot use javascript.
Is there a way to disable a button after clicking a button in asp.net?
Since you want to disable the button after the user has clicked (and while your page is still loading) it has to be done on client side. JavaScript is the only client-side language you can use for this.
So make sure that if the user has Javascript disabled (highly unlikely these days), that your end-page can deal with "double submitted" data.
Short story, no.
In your situation, you would need to make some server side code to detect a double post, and then discard the duplicate request.
You can start timer on server after each button click and put it in session. On next click you can check timer and apply or decline next user click.
So it will be impossible to disable the button without some kinda of client side scripting. If you assume that it will be disabled, no matter what kinda of client side script it is, then that's an impossible task.
What you can do is ensure that the operation they're trying to perform won't ever be run more than once per page load.
When loading the page create a hidden field; populate that field with a GUID.
At the start of the server side click handler enter a Lock block.
Check for the existence of a session key based on that GUID. (Give it a prefix so it won't collide with any other GUID based session key.)
If the key existed, exit the lock block and do nothing, or display an error message of some sort.
If they key didn't exist, then add a new value to that session key, exit the lock block, and do your operation. Give the session key an appropriate expiration time; it shouldn't need to be more than a handful of minutes. You could even remove the relevant session key at the end of the operation, if it makes sense for it to be repeated at that point.
in button click event just write the code
{
//Some Code
button1.Enabled = false;
}
What event I should handle to react to the completed change of the TextBox (i.e. when the user is
finished editing the content of the TextBox)?
There are several methods that you can use: Leave event, or a manual "typing stopped" event.
The Leave method is the most straight forward way of doing it, although as the event name suggests, it only happens when they TextBox looses focus, not when the user stops typing.
The TypingStopped event is something you would need to create yourself, but the basic idea of it is a short duration timer (say 500ms, but you would need to test it), which you restart on every KeyDown event of the TextBox. The timer would fire its own event and disable itself if it ever hits the end of it's timeout.
Edit: Updated to Leave event as per Hans' recommendation.
The Leave event is generally a good one for processing user input (for validation for example) as they move on to another part of the form. Just make sure that the event fires if they go from the textbox to any other UI element on your form - you may need to force a focus on the new element.
Are the two events the same or are there differences that we should take note when coding the keyboard presses?
My answer here is just based on experimenting with different applications, not programming per se.
Handle the keydown. Let that be the trigger for your logic. That's what the user would expect based on interacting with other applications.
For example, try a key down in Notepad, and you'll see that the DOWN triggers the reaction in Notepad. It doesn't wait for the UP.
It doesn't matter if it's .Net or not, it matters what the user expects. Keydown is a good time to respond to the four arrow keys. Character input is a good time to respond to input of visible characters. Keyup is usually a good time to respond to any action that is going to have an effect on a document, but keydown would be better if it's a game where the user wants immediate effect.
It's not really "which is a better choice for .NET."
You really have to think about how you want to respond to key presses. If you want to what someone is typing in a text box it's usually best to wait until they've released before trying to decide what they're doing. But if it's something like a game where you want to respond the instant it's pressed, than you would use KeyDown.
KeyDown is the moment the key is pushed down.
KeyUp is after the key has been released.
One thing to consider that I've had a problem with before:
If you handle something on key down that changes the window or changes UI component focus, then the new UI element may sometimes get the key up event.
This happened to me at my last job. We had a control on a form that, on key down, would load a new form. If the new form loaded fast enough, then the new form would get focus before the user released the key, and the new form would get the key up event. We had a UI control on that 2nd form that reacted to key up, and it would sometimes get triggered unintentionally.
The moral of the story is; keep it consistent. Pick one or the other and stick to it :)
The key down event happens as soon as the user presses a key, the key up event happens when they release the key after pressing it.
So if you use the key up event, and the user presses a key and holds it for 5 seconds, nothing will happen until they let go of it.
(Note: I know nothing about .net, I've just used 'key up' and 'key down' events in other libraries.)
I allmost allways use KeyDown, because then I can use e.Handled=True and stop the keyevent to travel from textbox to container and down in the eventque if I want. You can use e.Handled in KeyUp also, but then its "to late" because the key the user entered will be seen in the textbox and you have to take it away manually if you for example want to stop the user to enter digits in the textbox.
Another thing to take into account: When holding modifiers, it's important to use keydown. I generally use keydown to set a variable like ctrlPressed=true; then use keyup to unset that variable ctrlPressed=false;
I generally use keyPressed for all alphanumeric characters.
This sort of system allows you to enable things like CTRL+K+C ala Visual Studio