Region height is set up incorrectly after changing the monitor setup

[ALegkikh]

Hi,

I am using MaxTo v.2.1.15 and mostly is very satisfied with the software.

There is one thing that is disturbing me.

I am mostly using the notebook at work connected to a docking station and an extra-wide monitor (Samsung C49J89x). The monitor has a resolution of 3840x1080. The MaxTo is configured to use the standard "Ultra-wide three-way" region setup.

It works fine unless I take the notebook out of the docking station, used it with the internal monitor and then connected it back to the dock.

After that, the vertical resolution of the region is changed automatically the way that the taskbar is included in the region area. As a result, when a window is maximised in any of the splits, the bottom part of the window is not visible being hidden behind the taskbar.

The workaround is to re-apply the "Ultra-wide three-way" region setup manually:

1. Use the "Change regions" menu item
2. Use the "Presets" toolbar item
3. Use the "Load presets" menu item
4. Choose the "Ultra-wide three-way" item
5. Use the "Use regions" toolbar item

As I am taking the notebook home every day, I have to use the workaround every morning. Can it please be fixed?

Windows information:

Edition Windows 10 Pro
Version 20H2
Installed on ‎03.‎08.‎2020
OS build 19042.870
Experience Windows Feature Experience Pack 120.2212.551.0

Monitor information:

Kind regards, Alexander Legkikh

[github-actions]

Thank you for creating your first issue. We will get to it as soon as possible. This is an automated message designed to manage your expectations. We will most likely respond to your message during Norwegian business hours. If you should think of any additional information, please feel free to add it as a comment. If you are reporting a bug or incompatibility, make sure you include the versions of MaxTo, Windows and any incompatible program.

[vegardlarsen]

Thanks for writing. The issue is unfortunately known to us, and we don't have a solution at this time. The problem is related to the fact that MaxTo relies on Windows to send us a message when the working area of the screen changes (e.g. monitors are connected or disconnected), and MaxTo then immediately checks with Windows what the new working area is. What happens in this case is that Windows will report back with an incorrect (old) value, and MaxTo therefore misplaces the regions.

This can usually be worked around by quickly resizing the taskbar to be larger, and then resizing it back. This causes Windows to trigger an update, and MaxTo will be able to read the correct regions.

[ALegkikh]

Hi, Thank you for your answer. Looking forward to fixing Windows that will resolve the problem. 😁😆😂 And thank you for the the very useful software you made! Happy Easter! Kind regards, Alexander Legkikh

…

On Sat, 27 Mar 2021, 08:31 Vegard Andreas Larsen, ***@***.***> wrote: Thanks for writing. The issue is unfortunately known to us, and we don't have a solution at this time. The problem is related to the fact that MaxTo relies on Windows to send us a message when the working area of the screen changes (e.g. monitors are connected or disconnected), and MaxTo then immediately checks with Windows what the new working area is. What happens in this case is that Windows will report back with an incorrect (old) value, and MaxTo therefore misplaces the regions. This can usually be worked around by quickly resizing the taskbar to be larger, and then resizing it back. This causes Windows to trigger an update, and MaxTo will be able to read the correct regions. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#713 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMIQHRYNW3X7XMMDPFU6CVDTFWCVLANCNFSM4Z23NRKQ> .

[vegardlarsen]

I have made some small changes that could improve this in some specific cases. MaxTo listens to some events to determine when it should check if the working area has changed. Previously, it listened for SystemEvents.UserPreferenceChanged (limited to Desktop changes) and SystemEvents.DisplaySettingsChanged. I have now also added SystemEvents.SessionSwitch and SystemEvents.PowerModeChanged to that list, and removed the limitation on SystemEvents.UserPreferenceChanged. All of this is behind a debounce timer, so it shouldn't cause any unnecessary events/reloads.

If this is a bug in MaxTo, this should alleviate some of the symptoms. This change will be in 2.2.0-beta.3.