Sign in to follow this  
Headkaze

[.net] MouseUp event triggered on titlebar doubleclick

Recommended Posts

Headkaze    607
When a user double clicks on a window's titlebar a MouseUp event is triggered. It doesn't make sense to me that this event is triggered. Does anyone know of a simple fix for this? Perhaps a way to detect the resizing of the window to ignore MouseUp event during this period? [Edited by - Headkaze on April 3, 2010 1:39:47 AM]

Share this post


Link to post
Share on other sites
Headkaze    607
I made a mistake in my original post. The message is MouseUp not MouseDown.

To replicate the behaviour start a new project in Visual Studio and add a MouseUp event.

private void Form1_MouseUp(object sender, MouseEventArgs e)
{
MessageBox.Show("MouseUp");
}


Run it and double click on the titlebar to maximize the window and it should display the message box.

Share this post


Link to post
Share on other sites
ernow    732
Yes, that is what I saw in my experiment too.

The only solution I see is by subscribing to the SizeChanged event and checking there whether the form got maximized (WindowState). If so, set a bool and check for the bool in the mouseup, resetting it when it was set. That way you ignore the MouseUp from the resize.

It's a hack but the only thing I could come up with.

using System;
using System.Diagnostics;
using System.Windows.Forms;

namespace WindowsFormsApplication1
{
public partial class Form1 : Form
{
private bool _justMaximized = false;

public Form1()
{
InitializeComponent();
}

private void Form1_MouseUp(object sender, MouseEventArgs e)
{
if (_justMaximized)
{
_justMaximized = false;
return;
}
Debug.WriteLine("MouseUp");
}

private void Form1_SizeChanged(object sender, EventArgs e)
{
Debug.WriteLine("SizeChanged");
_justMaximized = (WindowState == FormWindowState.Maximized);
}

}
}




[Edited by - ernow on April 3, 2010 10:25:11 AM]

Share this post


Link to post
Share on other sites
Flimflam    665
It's probably happening because by the time you release the second click, the form has already maximized, and your mouse is now within the context of the form, thus you receive a MouseUp event.

Share this post


Link to post
Share on other sites
Headkaze    607
Quote:
Original post by Flimflam
It's probably happening because by the time you release the second click, the form has already maximized, and your mouse is now within the context of the form, thus you receive a MouseUp event.


Let's face it, it's a bug. Thanks for the example ernow.

Share this post


Link to post
Share on other sites
TheTroll    883
Quote:
Original post by Headkaze
Let's face it, it's a bug. Thanks for the example ernow.


Nope, it is working exactly the way it is suppose to. It is not a bug, it is expected action.

theTroll

Share this post


Link to post
Share on other sites
Headkaze    607
Quote:
Original post by TheTroll
Nope, it is working exactly the way it is suppose to. It is not a bug, it is expected action.


I don't agree. There is no possible purpose this could be useful. Even so this behaviour has been annoying on at least 3 apps I've written that use the mouse for drawing.

Share this post


Link to post
Share on other sites
Rattrap    3385
Quote:
Original post by Headkaze
Quote:
Original post by TheTroll
Nope, it is working exactly the way it is suppose to. It is not a bug, it is expected action.


I don't agree. There is no possible purpose this could be useful. Even so this behaviour has been annoying on at least 3 apps I've written that use the mouse for drawing.


MouseUp on Canvas from MS Forums. It inlcudes an explaination of why it happens and another way around it.

Share this post


Link to post
Share on other sites
Headkaze    607
Quote:
Original post by Rattrap
MouseUp on Canvas from MS Forums. It inlcudes an explaination of why it happens and another way around it.


I didn't read any explaination or way around it. The last post is by the OP pasting in his onclick event with no solution. In his post before this he asks if it's "by design" and that it "can't be the desired behavior" and "is extremely problematic.".

Share this post


Link to post
Share on other sites
Rattrap    3385
Quote:
Original post by Headkaze
I didn't read any explaination or way around it.


Quote:

Whenever you want to not handle an event because of it's spurious origin, simply detect this case in the event handler and set e.Handled to true in the EventArgs.


See the previous posts in this thread.

Quote:
Original post by ernow
The only solution I see is by subscribing to the SizeChanged event and checking there whether the form got maximized (WindowState). If so, set a bool and check for the bool in the mouseup, resetting it when it was set. That way you ignore the MouseUp from the resize.


So what he said was detect when the undesired behavior, as shown by ernow. And set e.Handled to true and return from your mouseup handler.

Quote:
Original post by Headkaze
In his post before this he asks if it's "by design" and that it "can't be the desired behavior" and "is extremely problematic.".


Quote:

You're seeing this because double clicking the Window's title bar results in maximizing the window. So, while your double click is still "in progress", the canvas expands to be underneath the mouse cursor but the mouse button is still held down.


It seems very logical to me that the mouse up event fires, even if it is inconvient. A click has occured, which means the mouse button did go down. So it doesn't seem like a strench to expect a mouse up event to occur. In fact, if anything I'm more surprised by the lack of the mouse down event.

Share this post


Link to post
Share on other sites
Flimflam    665
Quote:
Original post by Headkaze
Let's face it, it's a bug. Thanks for the example ernow.

What on earth are you talking about? It's completely expected behavior. Since the cursor is placed in the appropriate area to fire the event area before you release the mouse, it fires the event.

Just because it's inconvenient for you, doesn't mean it's a bug.

Share this post


Link to post
Share on other sites
TheTroll    883
This comes from the current frameworks and languages have abstracted what is going on under the hood so much that people don't really understand the way things work.

I think everyone should do a windows API app just once so they can see the way Window's messaging works.

theTroll

Share this post


Link to post
Share on other sites
Headkaze    607
I have written Win32 API applications in C++ before, this is not the point. Expected behavour doesn't mean it makes sense. I call it a bug because you are double clicking to maximise a window. That should be considered one event; a resize event.

Quote:
Original post by Flimflam
Just because it's inconvenient for you, doesn't mean it's a bug.


Just because Microsoft say it's right doesn't make it right. I've found bugs in Windows before so it's not the first nor will it be the last. What is the purpose of a double click to maximize also generating a MouseUp event? What could you possibly use that for? Obviously it's pointless and a PITA to have to work around it.

Share this post


Link to post
Share on other sites
TheTroll    883
Actually it is not about "generating" the event, it is about who is consuming the event.

Every time the mouse is released a "mouseUp" event is triggered, that is core to the system. The issue is who is handling that event.

On the maximize, the title bar is receiving and consuming the "double click". That makes perfect since. But the mouse has not come up yet and there is no reason for the title bar to consume the up event because it doesn't care, because the mouse is no longer in the title bar area.

Do you really think it would be a good idea for the title bar to be able to consume mouse events when the mouse is not in the title bar?

theTroll

Share this post


Link to post
Share on other sites
Rattrap    3385
Quote:
Original post by Headkaze
Just because Microsoft say it's right doesn't make it right.


Since .NET is a Microsoft product, it really is up to them what is right and what isn't.

If you don't want to deal with how the product works, then you have a couple of options.

If you feel it really is a bug (which most of the evidence says it isn't), then go to Microsoft's website and write up a ticket on it. I've written up tickets on MSVC before, and they usually response quickly. If it is desired behavior, they will usually respond back with that as an answer, otherwise they will acknowledge it as a bug and look into a fix.

Otherwise, I'd suggest looking for a similar product or just use the Win32 API.

Share this post


Link to post
Share on other sites
Niksan2    265
Surely it's just because the doubleclick happens on a mousedown event so you get all the garbage below.

And because the mouse up event can happen at any time, even a hour after you double click if you so inclined I'm not even sure how this could be fixed, because you could keep the mouse down, move to another window, right click and let the left mouse up, I can only image the overall crayness that could happen. So errno's solution seems the best route.



msg=0xa3 (WM_NCLBUTTONDBLCLK) hwnd=0x111a9a wparam=0x2 lparam=0xc4014d result=0x0
msg=0x112 (WM_SYSCOMMAND) hwnd=0x111a9a wparam=0xf032 lparam=0xc4014d result=0x0
msg=0x24 (WM_GETMINMAXINFO) hwnd=0x111a9a wparam=0x0 lparam=0x3c6dba8 result=0x0
msg=0xd (WM_GETTEXT) hwnd=0x111a9a wparam=0xff lparam=0x3c6d38c result=0x0
msg=0x46 (WM_WINDOWPOSCHANGING) hwnd=0x111a9a wparam=0x0 lparam=0x3c6dbb4 result=0x0
msg=0x24 (WM_GETMINMAXINFO) hwnd=0x111a9a wparam=0x0 lparam=0x3c6d404 result=0x0
msg=0x83 (WM_NCCALCSIZE) hwnd=0x111a9a wparam=0x1 lparam=0x3c6db88 result=0x0
msg=0x85 (WM_NCPAINT) hwnd=0x111a9a wparam=0xffffffff97041658 lparam=0x0 result=0x0
msg=0x14 (WM_ERASEBKGND) hwnd=0x111a9a wparam=0x3b012b27 lparam=0x0 result=0x0
msg=0xae hwnd=0x111a9a wparam=0x1001 lparam=0x0 result=0x0
msg=0xae hwnd=0x111a9a wparam=0x1001 lparam=0x0 result=0x0
msg=0xae hwnd=0x111a9a wparam=0x1001 lparam=0x0 result=0x0
msg=0xe (WM_GETTEXTLENGTH) hwnd=0x111a9a wparam=0x0 lparam=0x0 result=0x0
msg=0xd (WM_GETTEXT) hwnd=0x111a9a wparam=0x6 lparam=0x1ee2f8 result=0x0
msg=0x47 (WM_WINDOWPOSCHANGED) hwnd=0x111a9a wparam=0x0 lparam=0x3c6dbb4 result=0x0
msg=0x3 (WM_MOVE) hwnd=0x111a9a wparam=0x0 lparam=0x1a0000 result=0x0
msg=0xe (WM_GETTEXTLENGTH) hwnd=0x111a9a wparam=0x0 lparam=0x0 result=0x0
msg=0xd (WM_GETTEXT) hwnd=0x111a9a wparam=0x6 lparam=0x1ee318 result=0x0
msg=0x5 (WM_SIZE) hwnd=0x111a9a wparam=0x2 lparam=0x4780780 result=0x0
msg=0x83 (WM_NCCALCSIZE) hwnd=0x111a9a wparam=0x1 lparam=0x3c6d7e4 result=0x0
msg=0x85 (WM_NCPAINT) hwnd=0x111a9a wparam=0x3d04391b lparam=0x0 result=0x0
msg=0x14 (WM_ERASEBKGND) hwnd=0x111a9a wparam=0x1b012d50 lparam=0x0 result=0x0
msg=0xe (WM_GETTEXTLENGTH) hwnd=0x111a9a wparam=0x0 lparam=0x0 result=0x0
msg=0xd (WM_GETTEXT) hwnd=0x111a9a wparam=0x6 lparam=0x1ee2f8 result=0x0
msg=0x84 (WM_NCHITTEST) hwnd=0x111a9a wparam=0x0 lparam=0xc4014d result=0x0
msg=0x84 (WM_NCHITTEST) hwnd=0x111a9a wparam=0x0 lparam=0xc4014d result=0x0
msg=0x20 (WM_SETCURSOR) hwnd=0x111a9a wparam=0x111a9a lparam=0x2020001 result=0x0
msg=0x202 (WM_LBUTTONUP) hwnd=0x111a9a wparam=0x0 lparam=0xaa014d result=0x0




Share this post


Link to post
Share on other sites
Headkaze    607
Niksan2: I agree this whole problem stems from the doubleclick event occuring on MouseDown. If it was triggered on the final MouseUp this would not be a problem. So the question then is why.

Rattrap: If they haven't changed this by now I doubt MS will consider it a bug at all. Bug is probably not the correct word.. I'd say "irritating behaviour" would suffice but there are plenty of them. Every OS has them, so I don't think I'll be "changing products" because of it.

TheTroll: Why shouldn't it consume the final MouseUp event? It consumes the rest of the doubleclick mouse events, so why not the final one? The bottom line is a doubleclick event should occur on the final MouseUp.

Share this post


Link to post
Share on other sites
Flimflam    665
Quote:
Original post by Headkaze
TheTroll: Why shouldn't it consume the final MouseUp event? It consumes the rest of the doubleclick mouse events, so why not the final one? The bottom line is a doubleclick event should occur on the final MouseUp.


Why should a double-click be fired? The title bar is being double-clicked, not the form. There would be no double-click event fired.

However, the form is receiving a MouseUp because you're releasing the mouse in its region.

Share this post


Link to post
Share on other sites
Headkaze    607
Another irritating side effect of this. If you double click a file in the OpenFile dialog it will also register a click on the main form. Hohum.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this