Table Editor window position and size are not remembered

[ozobi]

The table editor window always appears at the bottom of my screen with only the toolbar visible. It doesn't remember the size or the position of the window.

Edition Windows 11 Pro
Version 22H2
OS build 22621.963

[RickStrahl]

It should remember the last window position which is stored in the configuration file. The easiest way to see if that works is to:

• Open the table editor
• Move it to a new location
• Close it
• Open it again

Does that work? It should.

If that works but it doesn't work after you shut down, then likely the settings are not being saved which is most likely due to the fact that the configuration lives in a location that's not disk writable.

You can check that after closing the TableEditorLeft, TableEditorTop, TableEditorWidth and TableEditorHeight values are updated in markdownmonster.json when you close the appplication (or you edit the file from the Settings window).

Also make sure of the following:

• If you're using a portable copy of MM make sure the Common folder where the config lives is writable.

[jbridgy]

The table editor window always appears at the bottom of my screen with only the toolbar visible. It doesn't remember the size or the position of the window.

I had a similar problem when the issue was posted 2 weeks ago. Now MM v2.7.14 restores the table editor window with the previous size but not at the previous position, if the position is not on the same monitor as the main editor.

[RickStrahl]

MM definitely remembers the position of the screen as outlined above. However, if you switch your screen layout between the time you close and reopen the editor the remembered values may no longer be valid or close to offscreen. If the Window layout stays stable you should see the window position preserved.

I have to double check and see if the TableEditor checks for offscreen or mostly window positioning as the main window does so that when it's too far offscreen it will re-center itself - this logic might not be applied to the editor window which would account for the behavior you see most likely.

[RickStrahl]

So I took a look at the code and it looks like the Table Editor is already using the Window adjusting logic.

I spent some time reviewing how this works, and playing with different DPI settings on multiple monitors and moving windows into locations that are no longer available etc. and as far as I can see MM is actually doing the right thing most of the time. It's doing the right thing all the time if you don't have different Window layouts, but if you switch between layouts and you last had the editor open in a different layout there are going to be scenarios when the editor doesn't pop up in an optimial position.

MM logic basically goes like this:

• First time opens inside of the dimensions of the main Markdown Monster Window
• Subsequent opens remember last positions and store it in the config settings
• Opens the Window and moves it to the last saved position
• Then finds the screen the window is on
• Adjusts for DPI ratio
• Finds the location of the window
• Checks to see if the window is larger than the screen height/width
• If not moves the window so it's fully visible within the view port
• Otherwise window is sized to the max size of the screen minus some padding

I think the scenario that is described by the two of you is where the screen layout was changed and MM happens to open in a location nearly offscreen but not quite offscreen so you get a partial window. There's no really good way to detect this and even if there was there's too much potential that upshifting the window causes problems on the other side.

Bottom line is this:

If the screen layout stays steady - even with multiple screens and DPI settings - you should have no problems with Window position sticking.

If you're changing layouts between invocations you may have issues with windows (including MM itself) not being fully visible and showing with just parts of the app displayed. If the Window is not visible at all or just about hidden, then MM will redraw it in fixed width.

I've made a small change and bumped up the tolerances for the Window margins where the re-location triggers, but I don't think that would affect the erxample in the screen shot above.

Finally neither of you @ozobi or @jbridgy has acknowledged whether you the window location actually gets written into the configuration or whether there's perhaps a permissions issue writing configuration values permanently.

[ozobi]

Hello @RickStrahl,

I have checked the configuration file as you suggested and it is updated correctly.

I am using two identical monitors on my desk in an extended configuration. The monitor on the right is primary, and the monitor on the left is extended. The DPI, resolution, and layout are not modified from start to shutdown.

I realized that MM behaves correctly if I am working on the primary monitor. The problem starts if I work on the second monitor. MM opens in the correct location when started, but the Table Editor window opens at the bottom of the screen. I recently found that I can fix this by moving the MM window to the primary monitor, maximizing and restoring the MM window, and then opening the Table Editor.

I installed MM using chocolatey if it makes a difference. I have an admin account on the computer.

[RickStrahl]

So you're running MM on the second screen and opening the Table Editor also on that screen?

So I just tried this here and here's what I see:

• Move MM to second screen
• Open Table Editor
• Table Editor Opens at last saved position on primary screen
• I move it to second screen and close it
• I open it again
• It opens in the location that I closed it in
• Close MM and restart
• MM Opens on second screen
• Open Table Editor
• Opens in the same location as last time (second screen in saved position)

IOW, it's doing what it's supposed to.

Can you tell me what's different on your end?

You should be able to quickly tell whether this works just by closing and reopening the table editor (without the shutdown which is just writing into the config file and reloading from there on startup).

[RickStrahl]

FWIW - unrelated to the TableEditor window placement - I reviewed the Window placement routines and found that the main window was actually using a different less efficient algo to figure out where to place the window if it's offscreen or mostly offscreen. That's been fixed and should result in improved placement for MM main startup.

So thank you for that 😄

I'm not sure what else to look at for the table editor window placement. I've spent quite a bit of time yesterday mucking around with the window placements and whenever windows are mostly offscreen MM figures out positioning and is moving things into the viewport.

The only thing I can think of is perhaps the actual Window layout/positioning of monitors? Perhaps above and below vs. side by side? Logic is weight towards windows that fall off on bottom and right vs. top and left.

[RickStrahl]

After some more experimentation I found an obscure bug that likely is the cause of the problem. So perhaps give this another try in v2.8.2.4+

[ozobi]

@RickStrahl, thank you for investigating this problem. I am traveling currently and away from my regular set-up. I will test your fix and report the result in 2 weeks.