Tdesktop: After minimizing TDesktop to the Sytem Tray, it does not open maximized again.

[doktormerlin]

Steps to reproduce

1. Open TDesktop in maximized mode
2. Minimize TDesktop to with the minimize button (not the close button) to the system tray
3. Open TDesktop again, using the tray. It is now opened in non-maximized mode

Expected behaviour

TDesktop should start again in the same orientation it was closed with.

Actual behaviour

TDesktop opens non-maximized, forcing you to click the maximize button again.

Configuration

Operating system: Windows 10

Version of Telegram Desktop: 1.2.10 alpha

[nerai]

It seems of the many duplicates this one stayed open. Just to be sure to avoid it going missing, there were some information on this topic posted in https://github.com/telegramdesktop/tdesktop/issues/1693 that I believe pinpoint the trouble to a specific part of the source. Sorry if you already processed that and thank you so much for developing this tool

[nerai]

I copy the information from #1693:

Maybe this is related to https://stackoverflow.com/questions/5673242 ?

[...] You are trying to persist your apps position and size when the app closes down so that you can restore it when it restarts. You are using GetWindowPlacement() to do so and have discovered that it returns an incorrect position when the last sizing of the Window was an Aero Snap.

My own app does exactly the same and I have encountered the exact same problem. The solution I used was to call GetWindowRect() in place of GetWindowPlacement() to obtain the window position and size.

GetWindowPlacement appears to be used in two positions in the source code. The first one seems to calculate the window position for a purpose that is not immediately clear to me:

https://github.com/telegramdesktop/tdesktop/blob/a76658ba467581dc13689b328340ec381d39d689/Telegram/SourceFiles/platform/win/windows_event_filter.cpp#L110-L127

The second one seems to relate to shadows, which I've also experienced as an occasional bug:

https://github.com/telegramdesktop/tdesktop/blob/a76658ba467581dc13689b328340ec381d39d689/Telegram/SourceFiles/platform/win/windows_event_filter.cpp#L140-L148

[nerai]

Additional information:

When dragging the window to a screen edge to maximize it, I noticed the program remembers the position of the mouse cursor at the begin of dragging. This is opposed to remembering the position of the window itself.

This causes the window to move around after restoration, and over time it moves almost out of the screen space. To prevent this, the window must never be dragged to a screen edge.

It seems like some other bug reports refer to similar behavior. Maybe fixing this would fix many of them, too.

[Aokromes]

cannot reproduce on 1.9.8

[pagefault]

Additional information:

When dragging the window to a screen edge to maximize it, I noticed the program remembers the _position of the mouse cursor_ at the begin of dragging. This is opposed to remembering the _position of the window itself_.

This causes the window to move around after restoration, and over time it moves almost out of the screen space. To prevent this, the window must never be dragged to a screen edge.

It seems like some other bug reports refer to similar behavior. Maybe fixing this would fix many of them, too.

I can confirm this behaviour on version 1.9.9, using 2 monitors on windows 10 1909. The same bug is described in #1693

[ilya-fedin]

Is this valid with 2.4?

[marhaus]

It seems to be fixed already in 2.3.1.

[nerai]

I cannot currently reproduce the bug with 2.4, hope it's gone :)

[Dahgoth]

Still persist in version 2.4.2 from Microsoft Store. Haven't checked version from website.

UPD: But if you snap windows and re-launch an app then it will remember snaped position and will remain in that position till you change size or move the window