Linked by Thom Holwerda on Mon 18th Dec 2006 22:27 UTC
Graphics, User Interfaces "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.
RE[2]: Start Menu
by DonQ on Tue 19th Dec 2006 17:53 UTC in reply to "RE: Start Menu"
DonQ
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).

Reply Parent Score: 1

RE[3]: Start Menu
by Doc Pain on Tue 19th Dec 2006 18:46 in reply to "RE[2]: Start Menu"
Doc Pain 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.

Reply Parent Score: 1