Printable View
Hi,
Does anyone know if you can remove focus from all controls on a form so a user doesn't inadvertently cause action on a control when it's unintended such as hitting Enter at the same time your app appears causing some action to occur? Do you have to leave focus on at least one control?
Thanks,
Rob
yes the answer is easy make something to focus on that has no effect and set the focus there
here to talk
I have never seen this be a problem, but I can think of one common scenario where it would be: You can set a button as an Accept button, or default button. This will cause hitting enter to act as a click of that button, which would be problematic if it happened too early. This would also have nothing to do with focus, though, so setting the focus anywhere wouldn't prevent this problem.
I think you are suggesting to put focus on a label or something like that, correct? Would you remove the TabIndex from all of the other controls?
the tab index is good when you are form filling or when your mouse dies apart from that you do not really need it
here to talk
Don't remove the TabIndex for this. That index is far more valuable than that.
Frankly, I think the solution is probably in error because the problem has been misidentified. If the user hits enter before the app appears, then nothing should happen. If the user hits enter after the app appears....then shifting the focus isn't going to solve a thing. The user can always hit enter at any time. If the time they hit enter is incorrect, the program has to deal with it. Otherwise you are creating a program that is so fragile that it will only work if the user makes no mistakes. I've never known such a user. Shifting the focus to another control won't work, because the user might be interacting with one control at the time that they hit enter, in which case the focus is going to have to be on that control.
Something else is wrong. It's not a matter of which control has focus, it's a matter of the program being written in a fashion where it is intolerant of mistakes.
these are design choices the programmer has to make
here to take
You could ask the user if that indeed is the choice the user wants.
It's all a matter of design, just as incidentals and Shaggy has said.
For example: The user is downloading a file, the Cancel Download button has focus. The user presses spacebar. The program asks if he is sure that he wants to cancel the download.
And it all could be as simple as setting the focus to another object, for instance another button:
vb.net Code:
As long as that question is being asked, I don't think anything more needs to be done. The problem would be if the program was written such that that question was NOT asked, and Cancel resulted in Cancel, without any chance for mistakes.Quote:
Originally Posted by Zeelia
I'm not sure that can be done effectively. When should the focus be changed? In your example, it would appear that you could clearly shift the focus away from the Cancel button when the download began, but how could the focus have gotten to the Cancel button in the first place? It can't be because the user clicked on the button, or the download would have been canceled. The only other alternative would be tabbing to it, but if that were the case, then you can't just shift the focus away when the download begins, because the user could just shift the focus back. So when could you safely shift the focus? Never. If the button is to have any meaning, then it has to be reachable by mouse or tabbing or hotkey, so it is always possible for it to have the focus by a legitimate means, and it is always possible that the user could inadvertently trigger the control when it has the focus.Quote:
And it all could be as simple as setting the focus to another object, for instance another button:
vb.net Code:
In other words: Yes, it would be easy to move the focus, but there is no safe time to do so that prevents the issues. The better solution is what you stated first: Write the program to tolerate mistakes. Maybe the user hit cancel intentionally, maybe they didn't. If it matters, ask them. If it doesn't matter, then don't worry about it.
This application is designed to run prior to patches when closing of applications or a Windows restart is required. It gives a user an opportunity to postpone a patch from running until it is most convenient. The Postpone button is what is in focus at runtime. The only other button is Install Now. When it runs, it is set to be on top of all windows so it takes focus away from an application that a user was working on at the time. If they happen to hit the Enter key because they were typing, they inadvertently postpone when they may have preferred to install now.
My preference would be to remove focus from all buttons which would require a deliberate mouse click to take action. If you want to postpone or install now, you'll have to click on the button of choice.
I'm not sure if you're allowed to remove the TabIndex from all controls which would hopefully achieve what I am looking for.
Well, if you explicitly, deliberately want a MOUSE CLICK, then you can disable spacebar/enter clicks on the buttons. (Although I wouldn't go with this since you should always be able to do as you want, as a user. You'd have to think of different scenarios, such as if the user doesn't have a mouse etc.)
Also, by design, I think it's alright to keep the focus on the postpone button, because if you accidentally click it, there is always another way to start the application, right?
Most convenient way would be a tray icon, IMO.
I hate programs like that. Preemptively removing the focus from the existing app is utterly infuriating to the user. If that's acceptable already, why worry about them getting the wrong button? It's one of my pet peeves, and it is really common. VS does it, even. If I am writing in a document, launch VS, go back to writing, then as soon as VS is ready, it pops up and takes away focus in mid stream. I HATE that.
Still, in your case, you have to make sure that the AcceptButton and CancelButton properties are not set for the form, or else nothing else you try will matter. The behavior you just described actually sounds more like an AcceptButton issue than a focus issue, so make sure that isn't the case. The AcceptButton will be triggered when Enter is pressed, regardless of where the focus lies (as long as it is with the app at all). If the AcceptButton property is not the source of this problem, then when the form loads, you should explicitly set focus somewhere that won't cause harm. Any control other than one of those buttons sounds pretty benign. Getting rid of tab indexes will just mean that tabbing on the form will make the user doubt either their sanity...or yours...and the last thing you want is them showing up at your door with an axe while foaming at the mouth.
If you hit Postpone, the application hides and then reappears when the timer has 15 minutes remaining. The user can choose to postpone again if needed.
I agree with you, if I program the buttons to ignore the space bar and enter keys, it doesn't really matter what is in focus. I'll research how to do that.