Window resets position on game restart - maybe related to position\size

Issue Description: Many users report the GameInfo window resets its position after game restart.
The GameInfo window is designed to be 40px height but i know the min window height is 100px (which is non sense and i dont understand really why).
The window, for his function, should be on bottom and docked there. If the user move it dragging, i save that the window has been moved, and at game restart i (should) dont move it again maintaining last user position.
But on some configurations, for what i could understand, who have large screens, they find the window in a wrong position (margin bottom from the screen bottom), drag it at the bottom, then at next restart the window back in the wrong position

Steps to reproduce:
Correct position (dragged): https://cdn.discordapp.com/attachments/773244451363356692/773506338402861116/Euro_Truck_Simulator_2_Screenshot_2020.11.04_-_12.17.04.77.png
Resetted position (wrong): https://cdn.discordapp.com/attachments/773244451363356692/773506617362219008/Euro_Truck_Simulator_2_Screenshot_2020.11.04_-_12.17.48.49.png

Impact for my app: [low, mid, high, show-stopper]: high

Do you currently have a workaround? No, i have tried to fix it setting a margin bottom -60px while positioning to fix the 100px fixed height canvas

The relevant window is GameInfo window
14-04.zip|attachment](upload://zq8OTLLI1uflK59KAkZTX5GDB80.zip) (972.7 KB)

Hi, and thanks for the feedback.

We will check the issue, and we will update you here.

Thanks.

1 Like

@dowmeister I can’t see the images. The links are broken. Also, do you know some details about the problematic configuration? Which DPI? Are you able to reproduce it? Do you have a movie that shows the issue?
Anyway, when placing the window on the initial place - are you taking into count the current DPI in your calculations?

Correct (dragged from the user)

Wrong (at game restart)

Also, do you know some details about the problematic configuration?
No
Which DPI?
I dont know, high DPI maybe?
Are you able to reproduce it?
No, tried many times
Do you have a movie that shows the issue?
No, because it’s quite simple: at game restart, the window is not in the previous position.

Anyway, when placing the window on the initial place - are you taking into count the current DPI in your calculations?
I move it with moveWindow overwolf function, i thought this function is DPI aware

@eransharv do you have any update on this?

Hi.

  • Regarding the min size of 100px - AFAIK, you can override this setting by using the min_size flag in the manifest.
  • Regarding DPI-aware - move is DPI-aware for native windows. not for in-game windows.
  • I would check these manifest flags: start_position & keep_window_location. In addition, when you call obtainDeclaredWindow, check the overrideSetting param, that can override the manifest settings.

Anyway, I would say that the best solution is to “place” the window on the right place from start… I understand that you are trying to do that, currently without success. But I think that this is the right path. To find how to place it correctly in any screen resolution.

keep_window_location is already true.

but, at this point, sincerely don’t understand what I have to do exactly to make it work on all screens.

the need is: by default, the window must be docked at the bottom and sized 100% screen size on width.

i do this since the beginning and it worked fine, or at least work on many screens except ones with high/strange dpi.

at the restart, the window must remain in the previous position and I’ve added also a condition for dragged windows: if the user drag it, at restart i won’t move it.

i will check if it’s still working one more time but every week i have 2-3 people opening tickets for the same reasons and it’s becoming a bit frustrating

The fact that the window’s location is not saved after relaunch is one issue, and the fact that on big screens, the app’s window not docked correctly to the screen’s bottom is another issue.

Anyway, regarding the first issue - I could not reproduce it - after moving the window and then exit OW and relaunch OW + app - it popups on the last known location.

Regarding the second issue (window not “stuck” right to the bottom)- I guess there is a wrong calculation on your side. When do you move it to the bottom, and how? As I said, the movie is not DPI-aware (only for native windows). Can you please do some more tests on that? Maybe change your DPI and see if your “move” algorithm works as expected?

Finally i think i’ve fixed this issue: the problem was related to the min_size.
Don’t know why it didnt worked many months ago but now it works: the window is finally 40px height.
I was moving it at -60px bottom to compensate the 100px fixed height and when restored (using hotkey alt+g, so closed and restored), the position was resetted, maybe because the position restored was invalid (under the edge of the screen).

You can close the ticket and thanks for the help.

@dowmeister great! Thanks for the update!

Unfortunately i have to reopen this ticket because the bug just appeared again.

Reproducted here:

And attached Overwolf logs.

Please try to fix this, a lot of users (and some popular streamer too) have this problems and they deal with it daily.

About this user, in particular, he said the overlay position started to resets 4-5 days ago.

He is using Reshade and has an ultra wide screen.

OverwolfLogs_2021-01-11_08-43-30.zip (1.2 MB)

@dowmeister don’t you think it’s related to this ticket?

Yes, duplicated. I thought it was better open a dedicated ticket

@dowmeister I see that all of your app windows include the “override_on_update” flag, this explains why these windows changed their location once you updated your app (on Jan 3rd).

Please try to remove this flag and update us

Better continue here Windows on Wide screen have height higher than normal and resets position on restore - #7 by dowmeister and no, the issue is not related to override_on_update because that flag is there since 1 year and the issue is starting to become worrying since two weeks.

Per your request that it’s a duplicate, I’m closing this ticket.
We will continue here:

@itayG @dowmeister FYI