"Snippets Template" window starts slightly off-screen and corrupts form close button

[Smurf-IV]

Start MM V 1.21.1 (on monitor 2) Click the snippets button Window opens and is off the edge of the screen (edge of monitor 2)

Dragging the window back into the centre of the app makes the "Close Form Button" corrupt (Or is it already corrupted ?)

[Smurf-IV]

This is not the only Form to have the corrupted "Close button" Open the Git form (Via the red plugin icon)

• Opens in the middle of the App (Yay can this be the default for plugins?)
• Shows the corrupt close without having it off screen initially or dragging it around.

[RickStrahl]

I'm not sure what you mean by 'corrupted'?

The reason for the offset is to have it out of the way so you can edit the snippet and see your document as you test. But - as you are noticing that can cause problems if you have your instance zoomed.

The addin probably should remember its location which is something that can be added.

[Smurf-IV]

The X looks like it is double drawn.

[RickStrahl]

Hmmm... I don't see that.

• Open Snippet addin at the right screen
• Window opens partially obscured
• Move to center

Examine X doesn't seem to be any less resolved than on screen opened window.

IAC, I really have no control over this as this is controlled by the MahApps UI framework that handles the window rendering. There will be changes to this in the near future as I move MM to v2 of MahApps in the near future which should help with a few small Window frame rendering issues like this.

[Smurf-IV]

As noted above, This "Corruption" also happens in the Git window, which does not appear off screen when shown. But it does not appear to be corrupted in the screen capture or the other default plugin. The reason mentioned is that I followed the snippets example code to create my own, and it has the corruption as well. so it possibly something to do with the way the code base for those 2 plugins has been written which causes this "double X" but the other plugins do something different...

[RickStrahl]

That can be caused by windows that span across multiple monitors. The 'secondary' monitor will (incorrectly) render the window in the primary window DPI which screws up the image. That's not really a bug, but rather an indicator in Windows to let you actually see which window is the primary window for which the Window renders.

Ask me how I know... ;-)

I spent that better part of the afternoon creating a generic EnsureWindowIsVisible() function that ensures that Windows are visible at the location last saved and if not moving it to a visible and fully rendered location. This applied to the Snippets window initially, but more importantly it's now also applied to the main window.

This ensures that if you run MM on a 4k screen, shut down, and then restart in 1080p MM will show a full window in the visible area even ion the 4k screen it was in the larger areas that 1080p can't show. It's been on my list to fix this...

[Smurf-IV]

Note on my setup:

• Both monitors are the same dpi
• Happens on Monitor 1 or 2
• Happens when only 1 monitor

[RickStrahl]

I don't see it. IAC there's not really any solution to this even if it is happening when you drag the window offscreen. With the new behavior windows will only end up offscreen if you explicitly drag them there, otherwise the new positioning should reposition it inside of the viewport in its entirety.