Issue when windows TaskBar is set to be on top of the screen

[mentalisttraceur]

Hello,

I've always liked having my ConEmu open at coordinate 0,0 (flush with top-left of my primary screen). I also prefer to have my TaskBar at the top of my screen (but on Windows I have avoided this for a while, because it usually causes issues precisely like this).

Basically, with the Taskbar at the top, this happens:

This is equivalent to behavior I've seen in many other Windows software(s), and seems, from my research, to have to do with using 'ScreenSize' instead of 'ClientSize'. (Now, I haven't done any UI development for Windows, so I am not sure where exactly in your code to look, else I'd submit a patch myself, but maybe that will help you figure it out.

Here is what I would expect the behavior to me in my usecase, when opening a fresh ConEmu window:

Also, I believe you may be tempted to say that the behavior experienced is correct. To this I would counter that 0,0 when the taskbar is on top (or on the left) should be considered to be at the boundary of the taskbar, not the physical screen. I also think that if I have a portable copy of ConEmu (which I do), and I move it from one machine where I keep the taskbar on the bottom, to a machine where I keep the taskbar on top (maybe I have a different monitor setup where they are more comfortable that way), it's reasonable to expect for ConEmu set to launch at 0,0 to appear flush with the screen's top-left on the former, but to appear flush with the screen's left edge and the taskbar's bottom edge on the former.

However, you may not find this convincing - if so, please consider this bit of evidence that Windows' own internal logic is more in line with my expectation. This is what happens when you move the window (using Win+Shift+Right) to a secondary monitor:

As you can see, it ends up being moved past the top boundary of the screen, because Windows internally considers the edge of the taskbar on the main screen to be equal to the edge of the screen on a secondary screen.

If you'd like, you could just point me towards the part of the code responsible for the window positioning, and I will gladly work on a patch to fix this myself.

[Maximus5]

Update to latest alpha before posting new issues

[Maximus5]

Even if your suggestion (with treating coordinates as working area) makes sense for single-monitor station, it becomes totally inconsistent in other configurations. Example on this sketch.

What "coordinates" will have upper-left corner of ConEmu's window?

Anyway, update to last alpha first.

[mentalisttraceur]

Hello. My apologies for the delay in reply. Over the last months I tried this on several of the latest (at the time) Alpha versions and all of the Preview versions, including the currently latest Alpha. The behavior is the same in all of them, near as I can tell.

I don't think it's inconsistent how you describe: In that diagram you drew, the coordinates (which would just be workspace coordinates instead of raw screen coordinates) of upper left corner are, let's say, -200, 50 (assuming you're 200 pixels from left monitor's right edge, 10 pixels below the taskbar, and the taskbar is 40 pixels wide like it is on my Windows 7 instance).

I agree it might be unintuitive/strange, but I think it's less unintuitive then having programs opening underneath the taskbar, and at any rate, this is how Windows already treats that situation. If I use the standard Shift+Win+(Left or Right Arrow) shortcuts while ConEmu has focus in your example, then when it gets moved over by Windows, it'll be displaced down/up by the width of the taskbar as it jumps between monitors. You can observe this behavior with any not-full-screen window when having taskbar on top, not just ConEmu.

[mentalisttraceur]

I meant "50", not "-50", in the above comment. Above comment is edited to fix that now.

[Maximus5]

Build 151015

[Maximus5]

No answer, closed