Conemu: Conemu does not "snap" properly

[musm]

I'm using windows 10. Open up conemu hold down windows button and then hit left or right. You will see that ConEmu does not fully snap the the edges and that there is a small gap between the sides of the screen.

[Maximus5]

Microsoft bugs must be fixed by Microsoft, don't they? But the bug was ignored for months...

http://answers.microsoft.com/en-us/insider/forum/insider_wintp-insider_desktop/desktop-coordinate-system-is-broken/9e6fd9ab-6d27-45e0-bb55-4c868cd6ac45

[Maximus5]

http://conemu.github.io/en/MicrosoftBugs.html#SetWindowPos-10

[musm]

I'm going to reopen this until MSFT fixes it or something. It's interesting that if you drag the conemu bar and snap it via the mouse it will actually snap properly but no via WIN+ left or right

[Maximus5]

When you drag the window - Windows do calculations internally.
When app call Move(0,0) - Windows put it in wrong position.

[musm]

Is there any fix yet from MS or workaround yet. I love conemu but this bug really bugs me :)

[kuttor]

Yes, I have this same issue -- very annoying. Basically when snapping the window using Windows 10 hotkeys, it leave gap around the left or right side, depending on snap, and the bottom.

[Maximus5]

The Windows bug is known and reported. But all you, folks, coming back here again and again, instead of forcing MS to fix it? Does this make sense?

[kuttor]

Apologies. Microsoft or not, it seems strange that it's isolated to Conemu.

[Maximus5]

@kuttor It is not isolated!

https://gist.github.com/Maximus5/d6ef8119c25937aee6bc110fc50bfe5a

[Maximus5]

https://twitter.com/ConEmuMaximus5/status/787075126458191872

[mbikovitsky]

@Maximus5, I'm not familiar with the codebase, but why not let Windows handle the snapping instead of doing it manually? Seems to me this is one of those things Microsoft does not want developers doing programmatically.

[Maximus5]

1. Windows does not snap windows without caption.
2. Quake mode.
3. Windows snapping is not available for "calling". GuiMacro would not work.
4. What about restoring window position and state on starting new instance?
5. And some more things.

[mbikovitsky]

Assuming the inability to programmatically invoke snapping is by design (I'm not a Microsoft employee, so I don't know for certain that this is the case), wouldn't it be best to let Windows handle it and document that you can't do it manually?

Restoring position, however, might still work. For instance, on my system the top-left corner of the screen is at (-7, 0), and when setting this position from the Settings screen the window moves correctly. Still, this isn't "true" snapping.

Also, when I disable the title bar, snapping still works when using the mouse to do it.

[Maximus5]

If you restore such snapped window, it would not be snapped.
Application can't determine if it's snapped.
Titlebarless windows doesn't snap. By keyboard. Also, don't forget there are other versions of Windows, the 10 is not the one.
Fullscreen windows.
I can remember much more problems...

[mbikovitsky]

These are all valid points, but what I'm saying is that perhaps the solution is to make snapping work correctly where Windows allows it, and document that it is unsupported for the rest of the cases. Better to have a feature that works in some well-defined cases, than a feature that half-works in all cases.

[Maximus5]

At last. User may specify in ConEmu setting 100% width and limited height in cells (and vice versa). And what they will have? Gaps!

[musm]

Considering the pros and cons: I tend to agree with @mbikovitsky points here.

[miniksa]

Hey @Maximus5,

@bitcrazed, our PM, found this SetWindowPos issue being discussed on Twitter the other day and filed it as a bug in my system. I followed up with the team responsible for rendering window placement and got the following answers to some of your questions:

• Is it a confirmed bug? Is it a feature?
  It's somewhat in the middle. I asked the team responsible for the window framing and they said they consider the invisible frame to be By Design. I personally believe by some technicality, the frame still exists but is just invisible for theming/styling reasons, so they don't consider it a bug exactly.
• Is there any workaround to put the window at the edge of the monitor working area?
  This is where I got you an answer. :) The team says that you can use the DwmGetWindowAttribute function (https://msdn.microsoft.com/en-us/library/windows/desktop/aa969515(v=vs.85).aspx) with the parameter DWMWA_EXTENDED_FRAME_BOUNDS to find the "visual rect" of the window as known to the window manager. A little calculation between that RECT and the one you already have for your window will let you know how many invisible pixels there are outside your bounds and let you compensate accordingly for the invisible border.

I hope that helps you out!
--Michael

[Maximus5]

[Maximus5/ConEmu] Conemu does not "snap" properly (I #284)

[musm]

I think this has been fixed?

[RReverser]

@Maximus5 I thought I was still running into this issue on Quake mode (and I've been using ConEmu for years now), but, on a fresh setup, decided to give it another go, and only after finally reading through various discussions almost accidentally found out that it goes away if I:

1. Set window width to 100% (this is understandable part).
2. Set Quake Style -> Frame width from -1 to 0 - this is also sort of understandable, but maybe worth specifically highlighting in docs?
3. After that you need to slightly drag the quake ConEmu window after which frame does disappear. This part was quite surprising to find out, and this is where I was usually giving up thinking that the option didn't have any effect. Is this a bug / do you need a repro screencast?

[mystrdat]

I'm trying the 190714 version through Cmder and it seems the bug isn't fixed. The window sizes are not saved properly, or perhaps they're not re-applied properly. If I save the window size as 100% height, it resets to 98% height on next start and is padded.