Skip to content

Remember window state when the program is closed#2088

Merged
colinator27 merged 5 commits intoUnderminersTeam:masterfrom
luizzeroxis:remember-window-state
Apr 19, 2025
Merged

Remember window state when the program is closed#2088
colinator27 merged 5 commits intoUnderminersTeam:masterfrom
luizzeroxis:remember-window-state

Conversation

@luizzeroxis
Copy link
Copy Markdown
Contributor

Description

Add a field on the settings file to store the current state (position, size, if maximized) of the main window so it can be restored when you load the program back again. It uses the Windows functions SetWindowPlacement and GetWindowPlacement, which should be fault proof. I'm not storing some properties because they don't seem necessary.

Deals with #2085

Caveats

I haven't tested this on multiple monitors because I just have one... would appreciate if someone could test this.

Notes

I renamed MessageBoxExtensions to WindowExtensions and put the code there to not create a bunch more files (not sure if this should be done)

@github-actions
Copy link
Copy Markdown

github-actions bot commented Apr 1, 2025

@VladiStep
Copy link
Copy Markdown
Member

But WPF windows have necessary properties that are not read only (Width, Height, Left, Top).
Have you tried to set them instead of using Win32 API?

@VladiStep
Copy link
Copy Markdown
Member

Oh, and WindowState too

@luizzeroxis
Copy link
Copy Markdown
Contributor Author

@VladiStep Just using that doesn't deal with some edge cases such as multiple monitors (apparently), so instead of dealing with all of that manually I think it's simpler to use the built in Windows functions.

Copy link
Copy Markdown
Member

@colinator27 colinator27 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems to work well on two monitors, and even when disconnecting one of them, it didn't seem to meaningfully break in any way.

Two things, though: Probably want to fix the indentation a bit, and also make this an optional setting (since I know at least personally, I sometimes have multiple tools open and don't want them interfering in the placement of new ones). I guess it can default to being on, though?

@luizzeroxis
Copy link
Copy Markdown
Contributor Author

@colinator27 I'm not sure you mean by the indentation. To be honest I'm not sure what indentation is supposed to be used on the project.

I added the setting but it's weird that this causes you problems since all settings are in one file for all instances of UTMT, so you'd think you'd have run into problems sooner.

@colinator27
Copy link
Copy Markdown
Member

For context on indentation, I mean the bottom of WindowExtensions.cs. Seems like it alternates between tabs/spaces, and it looks pretty ugly here on GitHub's diffs (guessing because it was partially copied from the linked code).

Also, I haven't actually run into any problems with this yet, not sure what you're referring to there.

@luizzeroxis
Copy link
Copy Markdown
Contributor Author

Sorry, I guess I misunderstood, I guess you meant that you just want multiple instances appearing in different places? And about the indentation, I didn't see anything weird on the GitHub diffs, and VS makes it hard to notice this kind of thing. Put everything to spaces, hopefully this works out.

@colinator27
Copy link
Copy Markdown
Member

Indentation looks good now, thanks! Also, I'm not expecting this to handle more than one window state at a time, that seems pretty infeasible... I think the setting as it is now is good. I'm fine with this PR as long as nobody else has any objections (probably want someone other than myself to review it as well).

@colinator27 colinator27 merged commit 08be393 into UnderminersTeam:master Apr 19, 2025
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants