| Date: | December 16, 2006 / year-entry #415 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20061216-13/?p=28703 |
| Comments: | 39 |
| Summary: | 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... |
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? For one thing, waiting for the completion of a mouse action means that you create the opportunity for the user to cancel it. For example, if you click the mouse while it is over a button (a radio button, push button, or check box), then drag the mouse off the control, the click is cancelled. But a more important reason for waiting for the press is to ensure that the press won't get confused with the action itself. For example, suppose you are in mode where objects disappear when the user clicks on them. For example, it might be a customization dialog, with two columns, one showing available objects and another showing objects in use. Clicking on an available object moves it to the list of in-use objects and vice versa. Now, suppose you acted on the click rather than the release. When the mouse button goes down while the mouse is over on an item, you remove it from the list and add it to the opposite list. This moves the items the user clicked on, so that the item beneath the mouse is now some other item that moved into the original item's position. And then the mouse button is released, and you get a You can also get into a similar situation with the keyboard, though it takes more work. For example, if you display a dialog box while the Alt key is still pressed rather than waiting for the release, the Alt key may autorepeat and end up delivered to the dialog box. This prevents the dialog box from appearing since it's stuck in menu mode that was initiated by the Alt key, and it's is waiting for you to finish your menu operation before it will display itself. Now, this type of mismatch situation is not often a problem, but when it does cause a problem, it's typically a pretty nasty one. This is particularly true if you're using some sort of windowless framework that tries to associate mouse and keyboard events with the corresponding windowless objects. When the ups and downs get out of sync, things can get mighty confusing. (This entry was posted late because a windstorm knocked out power to the entire Seattle area. My house still doesn't have electricity.) |
Comments (39)
Comments are closed. |
"For example, it might be a customization dialog, with two columns, one showing available objects and another showing objects in use. Clicking on an available object moves it to the list of in-use objects and vice versa."
I have a hard time coming up with a real-world instance of this behavior. The ones I can think of all either have a command button for moving selected items between the columns, require a double-click to move an item between columns, or both.
Isn’t the real reason that it is impossible to discriminate between a mouse click and a mouse drag before the mouse button is released?
Here’s a painful situation: Imagine that you have a DataGridView where you want to allow the user to drag and drop items around.. Typically you’ll call the DoDrag on the CellMouseDown, remove the item from the collection… And on a DragDrop event you re-add the item to the collection again.. A side-effect of this implementation is that when the user accidentally clicks on an item (but doesn’t drag it elsewhere) the item is lost…
This is one of the things that I really prefer on the Mac when using the mouse: menu’s (both regular and context) pop up on mousedown, allowing you to "drag" to the menu item and release the mouse to activate. It feels much better (as one action, instead of two seperate clicks.)
I always thought the reason this didn’t happen in Windows is because it is possible to actually drag with the right mouse button and get a drag context menu (e.g. in Explorer you get Copy/Move here and Cancel). I wonder if anybody actually uses that menu.
There’s more "presses" that need to be released further in the entry — <i>But a more important reason for waiting for the press</i>
I do, because I usually can’t remember the keys for forcing a copy or move, so I just drag with the right mouse button and use the menu.
I still remember my surprise to discover that double-clicks are actually processed on the second button-down, not on the button-up.
BTW, Windows menu bars work fine with the Mac system of clicking to drop down the menu and letting go of the button to choose the menu item.
It seems to me that a big reason is that you don’t actually know what the user intended on the button-down. I.e. for the windows key, you don’t know if they’re pressing windows-D, or windows-R, so processing on key-down is premature.
And IE7 closed a tab on middle button down (instead of up). Even Opera 9 does it incorrectly.
The start menu on XP opens on button down. Lets see how the submit button works on this form. I’ll click it, move away to cancel, and finish…
…this post. Cool!
It seems that combo keys work slightly differently. If I press and hold windows button, no discernible effect. If, while I’m doing this, I press and hold D, all windows minimize & restore repeatedly as long as I’m holding them down!
confused: That’s auto-repeat. If you hold down a non-modifier key such as D for long enough, the keyboard (not the operating system) sends releases for it automatically and repeatedly until you really release it. This doesn’t (or shouldn’t) affect the modifier keys. The key press is not repeated.
I thought autorepeat was an OS thing. In both Windows and Linux
(well, at least Ubuntu) there is a settings page for how long the
computer should wait until autorepeat comes in and how fast it should
repeat. Okay, this page could be sending these figures to the keyboard,
but I figured the keyboard just sent keydown and keyup events to the OS
and the OS turned them into keydown/keypress/keyup and autorepeated
versions…
Also it seems a lot of people have different actions on their
computers. I’m running XP and my start menu doesn’t come up until I
release the Windows key, and menus do activate on mousedown and I can
select an item on mouseup, but someone has said something to the
contrary for both of these. Weird…
Unfortunately, some menus do this and some don’t. For example, in XP:
Menu bars: yes
Context menus: no
Dropdown menus in Explorer toolbars: no
Classic start menu: yes
Top-level items in XP start menu: no
Submenu items in XP start menu: yes
Saturday, December 16, 2006 6:00 PM by Andy
I still wish I could put that menu on the LEFT button and then I’d be using it all the time. 90% of my drags are unintended and I would select Cancel 90% of the time. The other 10% I’d select what I wanted to do.
Sunday, December 17, 2006 10:06 AM by Ben Hutchings
If you hold down a key for long enough the keyboard sends PRESSES for it automatically and repeatedly until you release it. This DOES affect modifier keys. The key press IS repeated. On some devices the hardware doesn’t do it so the driver has to emulate it in software, some drivers don’t emulate it properly, and this month I have to figure out how to contend with them.
Raymond Chen:
Backwards compatibility of course. Some mechanical typewriters had that feature even before they were connected to computers.
Sorry guys. Typematic for USB keyboards is done in software. USB HID protocol does allow for it to be done in the keyboard hardware, however current Windows versions disable this.
> This is one of the things that I really prefer on the Mac
> when using the mouse: menu’s (both regular and context) pop
> up on mousedown, allowing you to “drag” to the menu item
> and release the mouse to activate. It feels much better
> (as one action, instead of two seperate clicks.)
And that’s one thing I’ve always *disliked* about Macs. I think it’s much easier to click once and then click again. Click and drag produces more stress on your hand (I believe). I suppose it goes along single button mice–requiring constant keyboard use to do anything more than a basic click.
> I wonder if anybody actually uses that menu.
Sometimes I do, but usually I use the CTRL, SHIFT, and CTRL+SHIFT modifiers when dragging items around.
> Autorepeat (known as typematic for some reason) is
> implemented in hardware. -Raymond
So is the slider in Keyboard Properties just for limiting how fast the repeat rate is translated? (So ‘Fast’ is full speed and anything lower means the OS starts dropping repeats.)
Hi, I read yourlast yr blog on ur old Notebook..
I have the same Fujitsu Lifebook B series n facing same issue..how can I install windows 98 on it as i just want to use it for internet…
It dont have a CD rom or floppy drive ..but bootable options are only HDD n Floppy drive..I have just formatted the HDD..appreciate if u can help in this..mail me at pixovation@gmail.com
Thanks
@Nisheeth:
Kind of off topic, but I had a similar problem recently with a toshiba portege 4400. In the end I borrowed a PCMCIA cd-rom which the system (thankfully) was able to boot from.
If you can get boot floppies made, on my system at least, any old USB floppy seems to work.
It should also be noted that for a button to send a BN_CLICKED notification, you need to both press and release the mouse button over the control.
Like you said, if you press on the button, then move away and release, the action is not performed. But similarly, if you press while not on the button, the move over the button and then release, there’s also no action (at least the BN_CLICKED notification isn’t sent; if the app subclassed the button and was actually listening for WM_LBUTTONUP I suppose the action would still take place).
Oh, how I wish I could convince my users of the wisdom of this scheme. They insist on having many actions happen on the mouse button down, so that they don’t have to keep the mouse steady while clicking on something. This results in no end of headaches for us in dealing with the difference between click and drag, and right-clicking resulting in a dialog box going away and the control underneath getting a context menu event on the mouse button up.
By waiting for the buttonup, we can tell the difference between click-and-drag, and a simple click.
Which is important, because we do different things on buttonup when buttonup ends a drag than when it just signals the end of a click.
For instance, Click (without any shift/ctrl etc) selects and item, and DESELECTS all other items.
But click-and-drag, DOES NOT deselect all other items. Not even if you cancelled the drag.
This behavior is so pervasive in good software, that we very often delay operating until the buttonup even when we don’t have a current need for drag. We do this just so that we don’t forclose the ability to add drag behavior in the future.
I just love this feature.
It often happens to me that I click a button and realize that it’s the wrong one. Then I can just move the mouse out and release the mouse button , that’s all.
The blog explanation is bogus. The reason is because of the need for drag and drop, as many other comments have pointed out.
I think that it’s on release because of the possibility of combinations which might have been discussed earlier.
For example, alt <release> is different that alt-F <release> and click <release> and control-click <release> are two different actions.
Think about closing a window. Yes, it always has happened on release. There are a number of times that I have almost mistakenly closed a window; only to catch myself and move the cursor away at the last second and release.
I can honestly see consistency at the heart of this.
if things happened on th action and not on the release then Things like CTRL+ALT+DEL would not work properly….
Check out the Preferences dialog in the latest Adobe Reader (8), the OK button performs its action on the release, however the Cancel button perfoms its action on the press. Go figure..
"
The start menu on XP opens on button down. Lets see how the submit button works on this form. I’ll click it, move away to cancel, and finish…
…this post. Cool!"
If you mouse click it, your correct.. the OP was referring to pressing the "windows" key on Windows compatible keyboards, in this case he is correct too.. but if he bothered to check the "why’s" he would have found there are many Shortcuts associated with Pressing this key in combination with other keys..
This may be the stupidest thing I’ve ever read anyhow, what difference does it really make, if it bothers someone so much that it works this way, change the behavior or don’t use it.
I feel your pain… I don’t have power at my house either… sigh… 4th day and counting.
As a programmer who did GUIs back in MS-DOS days I would like to say that "Action on release" is easier to implement. It is done naturally by everyone who did it back in those days. Doing action on click is a bit complex. So it is really a matter of laziness.
Maybe too easy for M$ Windows developers:
"To distinguish drag actions" (did you forgot last time you used this kind of feature? :-)
One of (many) annoying things I find about Internet Explorer 7 is that closing a tab using the middle mouse button does so mouse down and not mouse up.
"And that’s one thing I’ve always *disliked* about Macs. I think it’s much easier to click once and then click again. Click and drag produces more stress on your hand (I believe). I suppose it goes along single button mice–requiring constant keyboard use to do anything more than a basic click."
So then just click once and click again on the Mac if you want–it works both ways. :) (OK, only since System 7 point something, so they haven’t always had it, and it used to be that you had to enable it, but in OS X, there’s not even an option anymore.)
And surely you know you can hook up any multibutton mouse (well, except PS/2…) to your Mac, and it works as you would expect. Some, like the newer iMacs, even come with Apple’s multibutton Mighty Mouse by default. Not to mention that even with a single button mouse, click-and-hold will usually bring up a context menu as well without any need for the keyboard.
Now, a bit more on topic: interesting article! I never thought much about it before.
Off topic a bit, but in embedded systems, actions are always done on the release.
If 2 buttons are needed for an action, it’s only possible to know they are both down then register a release of one of them.
Apart from that, timed keypresses can only respond at release… e.g. how do you know a key has been down for 5 seconds at the press..?
I noticed this about the action-on-button up back in the 9x days and never thought about it. I think a lot of the explanations given in the comments are good reasons for this to happen. There isn’t just one or two reasons or the ones that were in the post. There are a lot.
Incidentally, Action-on-Release happens on both Windows and Mac OS. Additionally, selecting menu options in Windows and OS X work exactly the same way. You can either click once, point, click again, or click-hold, drag, release. Both systems support it.
Cool article.
I thought the action-on-release for buttons was so that computers could render visual feedback during the onclick state so that users would know that they have successfully activated something (as opposed to clicking on a "dead" area of the screen). The visual feedback prevents users from having to guess whether they clicked correctly and the action is just taking too long to complete or whether the software failed to detect their click or their mouse was broken.
PingBack from http://kafazov.net/blog/?p=142
PingBack from http://sarathc.wordpress.com/2008/02/17/276/
PingBack from http://sarathc.wordpress.com/2008/02/17/wait-i-need-to-release-my-mouse/