Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FloatWindow caption hit test is broken #644

Open
Summate opened this issue Jan 6, 2021 · 0 comments
Open

FloatWindow caption hit test is broken #644

Summate opened this issue Jan 6, 2021 · 0 comments

Comments

@Summate
Copy link

Summate commented Jan 6, 2021

There is an issue in WM_NCLBUTTONDBLCLK handling for FloatWindow where it will incorrectly dock the window if DoubleClickTitleBarToDock is set to false, but that's secondary. There are other issues that either cause this to happen occasionally or mask this issue from happening all the time.

Primarily, the code in Win32Helper.HitTestCaption is incorrect.

If we look at the code with the only modification of named parameters on the Rectangle constructor:

        internal static uint HitTestCaption(Control control)
        {
            var captionRectangle = new Rectangle(
                x: 0,
                y: 0,
                width: control.Width,
                height: control.ClientRectangle.Top - control.PointToClient(control.Location).X);
            return captionRectangle.Contains(Control.MousePosition) ? (uint)2 : 0;
        }

So if the FloatWindow is non-maximized, the X and Y position of the Rectangle will all but ensure that the test never passes as expected, because it would have to get the message while clicking in two places at once unless you move your restored window to the upper-left of the virtual screen space. I believe control.Location.X and control.Location.Y may correct this particular deficiency.

The next issue is height. I believe that formulation math works okay, but why would you use X for height? Shouldn't it be Y? Once you fix these two things, the test passes pretty much every time when you double click the caption.

Next up, Control.MousePosition may change at some point during handling, so you can have a situation where the message is being handled and the current position of the mouse is different from when the handling started, causing this test to behave erratically. It's not common, of course, but it is a logical issue. I believe it would probably be preferable to utilize the lParam of the message to get a reliable and stable position: https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-nclbuttondblclk

It also seems that the wParam is the result of a WM_NCHITTEST as well, so perhaps this test isn't necessary at all.

I'm fine with doing some testing and submitting a PR, but given the apparent confluence of issues, I didn't think it was a good idea to submit it without checking in to see what should ideally be done, how it should be handled.

To be clear, the context is that I have a customized FloatWindow as the documentation suggests with

			FormBorderStyle = FormBorderStyle.Sizable;
			DoubleClickTitleBarToDock = false;
			ShowInTaskbar = true;
			Owner = null;

The window maximizes seemingly correctly when double clicking the caption (I think this is because the test is erroneously failing due to the issues), but when I double click the maximized caption, it often re-docks the window. Occasionally, depending on where I click, it will go back to a restored state.

I believe the things I've outlined to be the reasons for this inconsistent behavior. Let me know how you would like to proceed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants