Improve Titlebar detection

[RamonUnch]

Related to #226 opened by @rp1231

There is a problem indeed with title-bar detection that deserves further investigation.
On Windows 10 the half lower part of the minimize button will respond HTCAPTION to the WM_NCHITTEST message instead of telling HTMINIMIZE as it should. This was highlighted here #83 (comment) by @Ichisich in a different context.
It is not always the case and I was thinking something can be done about it.

The idea is to check using the DWM api and the DWMWA_CAPTION_BUTTON_BOUNDS property to ensure we are not pointing to one of the caption buttons.
This may not be 100% reliable but it is worth trying.
I will post here future progress on this issue.

[RamonUnch]

@rp1231 and @Ichisich,
Here is a build of AltSnap+Hooks.dll that should fix a lot of false caption detection by checking that we are not in a the DWMWA_CAPTION_BUTTON_BOUNDS. It is not perfect and there tends to be an extra margin inside the dwm rect that excludes a bit more of the titlebar than it should but for the most part it seems OK.

hooks1.54test14_i386.zip
hooks1.54test14_x64.zip

EDIT:
In the Identify Window option you will have the information of wether or not the click you performed was done inside the DWM buttons.

[rp1231]

Thanks, It seems to be solved for me.
Seems to be working fine for the apps that I was having problems with.

[Ichisich]

Explorer wasn't affected since some time ago. Not sure if, because of a AltSnap or a Windows update.
But yes, Notepad++'s minimize button gets recognized correctly now.

One drawback with test14 is, that title bar actions and Move/ResizeUp don't work inside the button box any more.
This also affects applications with collapsed/hidden button-boxes, which still get somehow recognized by DWM:

Edit:.
Title bar actions aren't affected per se, But left and right mouse buttons are.

[Ichisich]

Suggestion:

AltSnap, prior to test14, was a bit inconsistent in handling the button box.
Minimize would be ignored, but maximize and especially close were mostly dominant.
A setting that let Altsnap ignore the button box entirely when enabled, and, as with test14, recognize it always when disabled, should satisfy all use cases.

[RamonUnch]

When there is the combination WM_NCHITTEST=2 (titlebar) and we are in the dwm buttons then AltSnaps assumes that we are in the minimize button.
Titlebar actions are for the most part applied even when you click on those buttons anyway, but for move and resize, it is not the case because you do not want to be unable to click normally on the caption buttons.

I prefer to have false exclusion of some area rather than AltSnap kicking in when it should not.

[Ichisich]

In my case, it's move (left mouse) and minimize (right mouse). ->maximize move+resize ->maximizehz moveUp
Both actions still function when mapped to mouse 4/5.
That's why it feels inconsistent, despite being technical consistent.

Just go absolute in both directions.
Always recognize the button box and ignore the button box entirely.
Personally, I can't even remember the last time the button box wasn't just a waste of space, considering AltSnap can handle all three operations by itself.

[RamonUnch]

Just go absolute in both directions.
Always recognize the button box and ignore the button box entirely.
Personally, I can't even remember the last time the button box wasn't just a waste of space, considering AltSnap can handle all three operations by itself.

Makes sense indeed, there should be a global option so that people can configure if the Caption buttons should be included or not in the titlebar.

Actually I was wrong, the caption is excluded frot the titlebar not depending on the action button but for the left and right mouse buttons.

So I guess there should be a way to enable/disable caption button actions for all mouse buttons as pleased.

[rp1231]

@Ichisich in the screenshot you posted of mozilla firefox, there seem to be no title bar buttons.
I also have firefox but I seem to have the normal window buttons on the right hand side.....
How/Why are they hidden in the screenshot?

Asking because I'm trying to understand the context of the problem that you have posted.

[Ichisich]

I collapsed them via the userChrome.css
.titlebar-buttonbox-container { visibility: collapse !important; }

[rp1231]

Ah ok I see, It's a custom firefox.
On another note,
Altsnap titlebar actions don't seem to work on the windows terminal titlebar in windows 11.

Here are the window details:

Also, windows don't get focused by single left clicking when the left mouse button is set to move in the titlebar actions.

I can create a new issue for this if needed but I didn't know if the issue was big enough to start a new thread for this.

[Ichisich]

Terminal by default is blacklisted.
MMBLower=*|CASCADIA_HOSTING_WINDOW_CLASS

You can delete *|CASCADIA_HOSTING_WINDOW_CLASS and the Terminal will be recognized.
The caveat is that the Terminal indicates the tabs as part of the title bar.
Workaround: #11 (comment)

Also, windows don't get focused by single left clicking when the left mouse button is set to move in the titlebar actions.

Can't replicate.
Is this checked:

[RamonUnch]

@rp1231 For Windows Terminal problems, I suggest you have a look at #11.

[rp1231]

Also, windows don't get focused by single left clicking when the left mouse button is set to move in the titlebar actions.

Can't replicate. Is this checked:

I'm referring to a single click action on the titlebar rather than a drag action.
Like you would do to focus a window if altsnap is not active.

I just tried the setting you mentioned, but it doesn't seem to work very well for me.
It's not at all consistent in windows 11.

Also enabling this setting causes a certain window to go into a disco mode(for lack of a better word):

explorer_gzXWs1XGJh.mp4