Linked by Thom Holwerda on Mon 18th Dec 2006 22:27 UTC
"If you pay close attention, you'll notice that most user interface actions tend to occur on the release, not on the press. When you click on a button, the action occurs when the mouse button is released. When you press the Windows key, the Start menu pops up when you release it. When you tap the Alt key, the menu becomes active when you release it (there are exceptions to this general principle, of course, typing being the most notable one). Why do most actions wait for the release?"
Thread beginning with comment 194274
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2006-10-08
"Thereby described scenario (dialog is stuck, waiting menu completion before displaying it) is possible - but if Alt key entered menu mode on keydown, then dialogs API had be designed to not stuck in this situation anyway."
Ah, I see, thanks! The usual behaviour (at least as I implemented it in projects) is to flush input at dialog startup, so there are no keystrokes in the input queue when the dialog is shown.
"Actually there are user interfaces, acting purely on keydown/mousedown events (some old graphics packages for example). No big problems (except impossibility to cancel actions)."
In most cases a "take back" / "undo" functionality is provided so accidently done things can be undone.
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Member since:
2005-06-29
Alt usually sets a status, so it has no autorepeat function.
Actually it makes both - sets status and generates repeating keydown events. All keys generate. Thereby described scenario (dialog is stuck, waiting menu completion before displaying it) is possible - but if Alt key entered menu mode on keydown, then dialogs API had be designed to not stuck in this situation anyway.
This is the problem with pointed article - first is taken current behavor, then some (but not all related) aspects are changed and then is concluded that such system doesn't work.
Of course it doesn't, if it isn't designed properly.
Actually there are user interfaces, acting purely on keydown/mousedown events (some old graphics packages for example). No big problems (except impossibility to cancel actions).