Table Editor window opens at bottom of screen

[JohnGoldsmith]

When opening the Table Editor, the window opens position just above the taskbar.

This is based on:

• MM 3.2.10 x64
• Windows 10 Pro 22H2 19045.4291

Please let me know if you need any other details.

Best regards

John

[RickStrahl]

The table editor should remember the last location it was opened... So perhaps it's been a while or you're running at a different resolution?

If for some reason it doesn't remember the location then you may have a permissions problem with your common folder where the Markdown Monster settings are stored (Portable version?).

[JohnGoldsmith]

Hi,

Interesting. The Table Editor window opens in the same position (as per the image) every time and through app and windows restarts. I'm not (knowingly) running a portable version.

MM is installed in AppData\Local\Markdown Monster. MarkdownMonster.json is in AppData\Roaming\Markdown Monster and the json file is being written to - for example open documents is being set correctly.

The WindowPosition looks like this:

"WindowPosition": {
    "Top": 0,
    "Left": 1516,
    "Width": 1536,
    "Height": 1688,
    "InternalPreviewWidth": 643,
    "PreviewTop": 0,
    "PreviewLeft": 0,
    "PreviewHeight": 700,
    "TableEditorLeft": 1585,
    "TableEditorTop": 334,
    "TableEditorWidth": 1360,
    "TableEditorHeight": 932,
    "PreviewWidth": 643,
    "PreviewDisplayMode": "ActivatedByMainWindow",
    "PreviewDocked": false,
    "SplitterPosition": 600,
    "RightSidebardWidth": 250,
    "ConsolePanelHeight": 100.0,
    "IsTabHeaderPanelVisible": true,
    "WindowState": "Normal",
    "WindowPresets": [
      "2500 x 1750,1050,350",
      "2250 x 1500,920,330",
      "1900 x 1020,730,310",
      "1600 x 850,600,300",
      "1250 x 760,445,270",
      "950 x 620,445,0",
      "770 x 560,380,0"
    ]
  },

It looks like the correct TableTopEditor value of 334 is being persisted, but not read maybe? I'm assuming that if permission are correct for writing, then they would also be ok for reading?

Does the above help? Let me know if you need any otehr details.

Best regards

John

[JohnGoldsmith]

...also just checked that adding a new item to WindowPresets(with MM closed) does get reflected in the main window drop down on opening MM.

[RickStrahl]

Hmmm... that's pretty odd. So can you do this:

• Open MM
• Open Table Editor
• Move to the top corner and make small enough to fit desktop
• Close Table Editor
• Re-open it

Where does it open? It should open in the same location you left it.

Same behavior if you shut down and restart MM.

This is the behavior I see.

There's some additional logic that kicks in to try and ensure that the window is visible on the active desktop, but if you didn't resize the screen or change DPI in between the restart that should never be an issue.

The MM main window uses that same logic BTW, so if there was a problem there you would see it with the main window in a similar way so I kind of doubt this is what the problem is.

[JohnGoldsmith]

Yes, those are the steps I've been trying (and double checked again just now), but it always opens almost off screen (as per the screenshot).

I'm very happy to do a screenshare with you if that would be helpful (probably tomorrow now).

Just to let you know that it's not a blocker as I can get to the window - it's just more mouse exercise :)

[JohnGoldsmith]

I'll just add my screen setup in case that's useful: Two screens main one (DISPLAY1) is on the right and the left one has a negative left value:

[RickStrahl]

Hmmm... that's very odd. I can't duplicate this and I've tried in a number of different ways. I don't see anything wrong with your setup either. Only thing I can think of is that somehow the screen location is misinterpreted, but based on two 4k displays in what looks like 100% I don't see what that would be.

Does the main MM window remember its position? It's basically using the same logic that the Table Editor is using to reset and adjust the position on the screen.

[JohnGoldsmith]

Hi, Yes, the main window does remember it's postion (mostly - see below).

I tried the following

• Moving main window to middle of (right) screen and restart - works correctly, shutdown position is maintained.

• Table Editor position also positions correctly after this, however now slight (1 inch or so) shift right in X position.

• Table Editor open, center window and close cycle, repeats above line behaviour.

• Open MM, snap main window to right half of right screen, open Table Editor and position center of MM window.

• Close Table Editor and main windows

• Reopen MM, observe window is same snapped position, but right hand edge is now about 25px in from right hand edge of screen.

• Open Table Editor and observe position has returned to bottom of screen position as per image in orignal post.

Ok, I seem to be making progress. It looks like the 'not remembering' (ie positioning at bottom of screen) happens when you launch MM after its previous session was snapped right.

So my steps to reproduce on my machine are:

• Open main window and size width and height to be within screen
• Open Table Editor and also set size and position
• Close Table Editor
• Reopen and observe correct size and position
• Close Table Editor and main window
• Open main window and snap to right
• Open Table Editor and observe correct size and position
• Close Table Editor
• Close main window (from snapped status)
• Open main window (observe entire window has shift left by about 25px)
• Open Table Editor and observe Top of window is position 25px off the bottom of the screen 2060 (screen height)-2035(TableEditor.Top)

My working theory is (based on ILSpy) that when snapped right mainWindow.Top == 0 and so the if block body in TableEditor constructor where the TableEditorLeft/Top etc are read doesn't execute, in which case the default behaviour (setting the size and position inboard of the main window) gets executed.

I'm just wondering if the following line:

base.Top = mmApp.Model.Window.Height - 60.0;

should read as ?:

base.Top = mmApp.Model.Window.Top + 60.0;

I may be barking up the wrong tree here. What do you think? Are you able to reproduce with main window snapping?

[RickStrahl]

The easiest debugging for this might be if you run with source. I can give you access to the source repository if you want to give that a try and you can look at the Table Editor code as it runs and see where the position assignment goes wrong.

[RickStrahl]

I'm not sure what could be different between your setup and mine. When I run the forms they don't shift when they are restored. The only time there's a change if the form is almost off the screen and then auto-repositions so the bottom of the form butts against the bottom of the screen. The -60 is to offset for the menubar and custom chrome of the form - it moves the window higher off the bottom of the screen.

The only thing I can think of is that perhaps somehow the DPI ratio is misrepresented on your particular setup. But it looks to me that you're running at 100% so the DPI ratio should be 1.0. If you can run the code that should tell us more. If you do, the code will be near the top of TableEditor.xaml.cs.

[JohnGoldsmith]

Great, thanks Rick.

I'm running at 125% so I just did a quick test and I get the same behaviour at 100%.

For the code, I'm hitting a few issues trying to do package restore. Do you have any recommendations on the most straight forward way to run the main project?

[RickStrahl]

Ah I see what's happening. The SupportPackages folder with the local NuGet packages was excluded by Git.

I've fixed that - give it another try now by repulling.

It worked for me on a local pull to a new folder, but that might be because those refs exist in another location on my machine - argh.

[JohnGoldsmith]

That works - thank you. I confirm I can now run the code. Will make a coffee and see if I can figure out wthe behaviour I'm seeing. Thanks Rick.

[JohnGoldsmith]

I’ve been able to run the code and I think my findings so far are that when the main window is snapped to the right, then mainWindow.Top == 0. This means that the TableEditorLeft/Top…. properties are not read and the default handling takes places.

This line, in TableEditor's constructor, looks like a mistake, but it may well be that I don’t understand the intention:

Top = mmApp.Model.Window.Height - 60;

I’ve changed it to

Top = mmApp.Model.Window.Top - 60;

And it seems to work as expected (on my system).

I added the code below and got the right behaviour (original code at the bottom). Note I only added the extra variables to help my own understanding. Also, I’m not certain of the intention of the first line (which I changed to an ‘or’ for my snapped scenario). My assumption is that if TableEditor position had previously been persisted then I’d want to load that irrespective of the main window’s position. (I suppose if the VirtualScreen size or dims had changed between sessions then I might want to reset too).

#if JG
            if (windowConfig.Left != 0 || windowConfig.Top != 0)
            {
                Left = windowConfig.TableEditorLeft;
                Top = windowConfig.TableEditorTop;
                Width = windowConfig.TableEditorWidth;
                Height = windowConfig.TableEditorHeight;


                //WindowUtilities.FixMonitorPosition(this);
                WindowUtilities.EnsureWindowIsVisible(this); // visible on screen
            }
            else
            {
                double horizontalInset = 20.0;
                double preferedWidth = mmApp.Model.Window.Width - horizontalInset * 2;

                double topInset = 120.0;
                double bottomInset = 80.0;
                double preferedHeight = mmApp.Model.Window.Height - topInset - bottomInset;

                Left = mmApp.Model.Window.Left + horizontalInset;
                if (width < preferedWidth)
                    Width = preferedWidth;

                Top = mmApp.Model.Window.Top + topInset;
                if (Height < preferedHeight)
                    Height = preferedHeight;
            }
#else
            if (windowConfig.Left != 0 && windowConfig.Top != 0)
            {
                Left = windowConfig.TableEditorLeft;
                Top = windowConfig.TableEditorTop;
                Width = windowConfig.TableEditorWidth;
                Height = windowConfig.TableEditorHeight;


                //WindowUtilities.FixMonitorPosition(this);
                WindowUtilities.EnsureWindowIsVisible(this); // visible on screen
            }
            else 
            {
                Left = mmApp.Model.Window.Left - 20;
                if (width < mmApp.Model.Window.Width - 25)
                    Width = mmApp.Model.Window.Width - 25;

                Top = mmApp.Model.Window.Height - 60;
                if (Height < mmApp.Model.Window.Height - 80)
                    Height = mmApp.Model.Window.Height - 80;
            }
#endif

I was also wondering if screen setup might have an impact on the logic?

So just to be clear, my setup is like this:

And I was wondering if one of these might change things:

What do you think? Does any of that make sense?

[RickStrahl]

I'm not sure what the repro scenario is though. I can't make it do the behavior that you describe regardless of where I have my main window and where I put the table editor. My screen setup is similar to except my secondary screen is not 4k (laptop screen), so it's not the environment. If you are working on your main screen the second screen shouldn't have any effect.

Maybe a screen share would be a good idea if you're up for it just to compare notes what's different about your setup vs. mine.

FWIW, I've not seen anybody else run into this - I suspect if this was a widespread issue I would have heard about it by now...

[JohnGoldsmith]

Hi, Yes, I'm sure you're right that if you're not hearing this from others then that does point to something odd on my system. I can live with this, but if you're keen to scratch the itch then by all means fire me an invite and I'll show you what I'm seeing.

[RickStrahl]

Thank you for your help with a screen sharing session and running the source.

The fix of using the correct TableEditorLeft and TableEditorTop configuration values is definitely the fix. The intent of that check was to see if the value is unset and if so size it to the same size as the main window with a slight offset.

The error wouldn't show unless the Main Window was at 0 offset which usually means the window is pinned and I think that was causing some weird behavior. I supose this could still happen in the following scenario:

• Table Editor coords are not yet set (ie. values are 0)
• Main Window is pinned

The issue here is that Windows reports funky coordinates for the pinned window.

Anyway it'll be updated 3.2.16+

In that case we may still end up once with the odd behavior you saw. But once you move the window to new fixed location it would then correctly remember that location.