Windows Coordinate System Oddity

[Reverend Jim]

This is yet another thing that everyone just accepts, but nobody can tell me why this decision was made.

Everyone is familiar with the Windows screen coordinate system where x and y values increase to the right, for x, and down, for y. What is not noticible until you start programming window positions is that the upper left corner of the screen does not have the coordinates (0,0) as you would expect, but (-7,-7). Even more curiously, using the Windows Info tool that comes with AutoIt, if you maximize any window you will indeed see that the window is positioned at (-7,-7) but if you move the mouse cursor to the top left corner, it has coordinates (0,0).

This makes absolutely no sense to me so if anyone has a reasonable explanation I am more than willing to shout it down.

I'm also curious if this is the same on Linux. I have no easy way of checking it out. I program apps using wxPython nd one of its features is being multi-platform. If Linux doesn't use the same coordinate BS then apps would not truly be portable.

[rproffitt]

From memory this is the area you paint in. The coordinate of the app might be at 0.0 but the border might be 7 wide so there are absolute windows coordinates, window bounding coordinates and so on. Try making the app full screen borderless and see what the spy says.

[Reverend Jim]

I'll give that a try. But it still defies logic. The border is a part of the window, and the upper left corner should be the leftmost and topmost pixel of the control. If I position my application window to (0,0) there is a 7 pixel space between the window and the edges. If (0,0) corresponded to the upper left pixel of the paintable area then top and left borders would be rendered off the screen, not 7 pixels in.

[rproffitt]

Apps will have screen coords for the app placement and then the client area of said app.
I see this mentioned widely but you can see it in one paragraph at https://docs.microsoft.com/en-us/windows/win32/gdi/window-coordinate-system

Note screen coordinates and client coordinates.

[Reverend Jim]

The system and applications specify the position of points in a window by using client coordinates. The origin in this case is the upper-left corner of the window or client area. Client coordinates ensure that an application can use consistent coordinate values while drawing in the window, regardless of the position of the window on the screen.

Obviously. When I am placing controls in a window, specifying (0,0) places the control at the top left of the client area. I would expect this behaviour.

But I'm not talking about window coordinates. I'm talking about screen coordinates.

[rproffitt]

I think it's explained by the following: "Au3Info allows you to get information from a specified window that can be used to effectively automate it."
The tool appears to be fetching client coordinates.

[Reverend Jim]

I hate to sound obtuse (or, even worse, BE obtuse) but I still don't get it. From the previous post I get that "client coordinates" refer to the paintable area of the client. I'm still talking about SCREEN coordinates. So if the AutoIt tool gives me (-7,-7) as the upper left corner of a maximized window, what exactly is it referring to? It can't be the upper left paintable pixel because (-7,-7) to any sane person if 7 pixels to the left and above of the origin.

Again, I can easily program around this. But why should I have to? And if 7 is some magical number, shouldn't this number be documented or fetchable so I don't have to hard code it in? Does it depend on some system setting that may change for different screen resolutions?

[rproffitt]

I'm sure there's a tutorial about Windows coordinate systems out there but from memory the client window is the area inside the borders you see in a non-maximized app. So if the app's border is 7, then from the client area to the top left edge of the app would be -7, -7.

If the client coordinates included the border then folk that write apps would have to query border width then adjust for that to place controls and other app elements.

So back to app placement we use screen coordinates and not the client coordinates. That is, place the app at screen coordinate x.y. And for a button, place the button at client coordinates x,y.

[Reverend Jim]

I'm not interested in the client area inside the app. I'm interested in positioning a window/app on the screen which does not have a border.

When I place a control in a panel in an app I use coordinates (0,0) to place it at the top left. This works regardless of what size border the panel has.

I expect that behaviour to apply consistently so that when I position my app on the screen at (0,0) it is placed at the upper left.

[rproffitt]

The tool you mentioned is reporting (according to what I'm seeing) the client coordinate because AUTOIT code may need that to say move the cursor to x,y in the app and then click there. But for app placement on screen, that would use the Windows desktop coordinate system.

I just thought of another reason a full screen app has a 7 or 8 pixel border. If a maximized app did originate as screen coord 0.0 then the app would have to never place text at 0,0 because of the aesthetics. Since Windows started way back when some of the coord system is to make life easier for coders. That is, if your app had to constantly add 7 to x.y to avoid putting text and objects right at the monitor border, what a painful thing to inflict on all that write code.

The more I think about this, the more I think they did the right thing.

[Reverend Jim]

If a maximized app did originate as screen coord 0.0 then the app would have to never place text at 0,0 because of the aesthetics.

I think you are still confusing screen coordinates with client coordinates. When I draw directly to an app using a device context (DC), drawing a pixel at (0,0) renders that pixel to (0,0) in the client. Assuming the client is a panel (in wxPython lingo), that is the topmost, leftmost pixel in the panel which is the first pixel INSIDE the border that surrounds the panel. If I want to draw pixels directly onto the screen (there are several apps that do just that including zoomit from sysinternals) then I fully expect that drawing a red pixel at (0,0) would turn the topmost and leftmost pixel red.

if your app had to constantly add 7 to x.y to avoid putting text and objects right at the monitor border, what a painful thing to inflict on all that write code.

I don't get why you are stuck on this? Drawing to an app window (which has a border) is not the same as drawing to the screen (which is borderless).

[rproffitt]

Looking around for example code to draw on the Windows screen rather than in the app. Hmm, interesting.

[Reverend Jim]

From Microsoft

The coordinate system for a window is based on the coordinate system of the display device. The basic unit of measure is the device unit (typically, the pixel). Points on the screen are described by x- and y-coordinate pairs. The x-coordinates increase to the right; y-coordinates increase from top to bottom. The origin (0,0) for the system depends on the type of coordinates being used.

The system and applications specify the position of a window on the screen in screen coordinates. For screen coordinates, the origin is the upper-left corner of the screen. The full position of a window is often described by a RECT structure containing the screen coordinates of two points that define the upper-left and lower-right corners of the window.

and

The system and applications specify the position of points in a window by using client coordinates. The origin in this case is the upper-left corner of the window or client area. Client coordinates ensure that an application can use consistent coordinate values while drawing in the window, regardless of the position of the window on the screen.

So if you are referring to an app you use client coordinates. When referring to the screen you use screen coordinates. There is no mention of a 7 or 8 pixel offset. It specifically states the origin is the upper-left corner of the screen

[rproffitt]

Try this. Bump the app window border up to something big, like 20 or more. What does the spy tool tell us now?

[Reverend Jim]

Changing the border width in wxPython is not an option.

[Reverend Jim]

I'm going to guess that at some point someone will point out that the desktop is essentially an explorer window (albeit a special one with no visible border). In that case I would have to reason that the client area is the visible part of the explorer window, which is the entire visible desktop. Based on that logic, the upper left pixel would be, using client coordinates, (0,0).

I recall something that happened many years ago when I went to a presentation by a local Commodore 64 user group. Somebody was demoing a midi peripheral called Band-In-a-Box. One of the attendees couldn’t understand how it could produce so much complex sound. His response to any explanation was an astonished, “but it only has an 8 bit bus”.

I sincerely hope I have not become “that guy”.

[rproffitt]

I think it's time to see if https://twitter.com/davepl1968 has an answer. While I can see a reason for the spy tool to give client coords vs screen coords and I did live near Redmond in the 90's I wasn't a MSFT engineer and only had to deal with Windows app development in about 1997 and on. Before that it was all about embedded work on a slew of microprocessors and of course, DOS.
Lucky me caught a seminar with Bill Gates talking about device independent graphics and the troubles with screen and app coordinates but that was around the Windows 1.0 days and given it was so long ago, the details are too fuzzy but it was leading edge back then.

Time to see if you can get the attention of people like Dave Plummer.

[UnabashedGeek]

I certainly don't know, but I wonder if the origin of this is something to do with the over-scan technology on cathode ray tubes (CRTs) where you can never be sure exactly which parts of the tube would be visible on a specific monitor. The 7 pixels may have originally been a safety margin, and the coordinate system was a way to simplify accommodating this, which is now baked into today's interface.

[Reverend Jim]

The desktop has no border. The entire desktop is paintable.

If I have an app with a window and I want to draw in the window, (0,0) is the upper-left-most paintable pixel, regardless of the border width. If I want to paint on the desktop then (0,0) should be the upper-left-most paintable pixel. When an app is being rendered (painted) to the top left corner of the desktop, the upper-left-most pixel of the app (border included) should map onto the upper-left-most pixel of the desktop.