Is there a "Client to Window" function in the API?

[SteveS]

I'm amazed that I just can't seem to find the function that converts a client point to a point within a child window. For example, in the WM_LBUTTONUP message you are passed a somewhat useless point there the origin of the coordinate system is the upper-lefthand corner of the client area of the application. Usually you'll actually want the coordinate based on the upper-lefthand corner of the window that was actually clicked.

I've found and used the ClientToScreen and ScreenToClient functions in the past, but the other necessary function "ClientToWindow" doesn't seem to exist. Before I reinvent the wheel for a Windows 3.11 function that I cannot find, can someone tell me that this function actually is?

Thanks

[VladimirF]

There is a big difference between client area and window area: the non-client part of a window IS NOT YOURS! You have delegated its management to the Windows. (That is unless you do a custom non-client processing, which still has nothing to do with the tasks you perform in the client area).
All that should matter to you is the client coordinates of the window that received that mouse message.
You can do a two-step conversion from one client to another via the screen coordinates, but if you have to do that, it means that you are processing messages directed to one window in another window. Which begs the question: why?

[SteveS]

That wasn't what I asked. I want to know the API function that convert a point in the client area of a window to a point within a child window.

[Paul McKenzie]

ClientToScreen using the parent window as the client, then take the results of this call and call ScreenToClient using the child window as the client.

It is a two-step process (as VladimirF pointed out).

Regards,

Paul McKenzie

[mdmd]

I think MapWindowPoints is what you want. But I have no idea
if it is available in the 16 bit compiler. Or what Paul just said !

[VladimirF]

You said that you know about ClientToScreen and ScreenToClient.
I suggested a two-step:
parent->ClientToScreen()
child->ScreenToClient()

Unfortunately, that process does not benefit from the fact that these two windows are in a parent-child relationship. It works for any two windows.

The fact that there is no ParentToChild() coordinate conversion leads me to believe that it is unreasonable to have. That is why I've asked my first "why". If you need to process a message in a child window, why not to handle it there and avoid that conversion?

[SteveS]

ScreenToClient does not help because it returns a point who's coordinate system is based on the origin of the entire client area of the app. I need a point based on the upper-lefthand corner of the window being clicked upon. I don't understand why I'm failing to explain this simple thing...

Say you have a dialog box with a window in the center. Trap the WM_LBUTTONUP message inside that child window's message map. Click at (1,1) in the child window, the point that you receive will be different than that, say (200, 100), because its based on the client coordinate system. When I'm handling that command within the childwindow, I want to handle that point as if it were based upon the upper left of the child window as (0, 0), not the client dialog window. That's what I need to convert to.

I'm not programming in 16 bit Windows, I only meant that this is functionality that should have existed in the API since the days of Windows 3.11. If we have ClientToScreen, ScreenToClient, we must also have functions like ClientToWindow or ClientToChild.

This is one of those roadblocks that the Windows API throws at you and I'm becoming increasingly annoyed at the gaping holes that exist in the API and their lack of interest in fixing these problems. I chouldn't have to write more than 1 line of code to get this value! I shouldn't have to reinvent the wheel! The API is supposed to handle these basic things and it is really annoying me how effing bad this API can be.

[VladimirF]

I feel the need to explain myself.
At first, I've misinterpreted you name "ClientToWindow". There are client rectangles and window rectangles, and I thought that your question was about that. Sorry.

Now I think that you are mistaken about "client coordinate system". In case of your child window, it is this window's client coordinates, not its parent's. Is your example with (200, 100) a hypothetical one? From what I know, if you clicked at (1, 1), the POINT that comes in a message is also (1, 1).

Anyway, while you are in a window, there are only two coordinate systems: this window client's, and screen's.
If you convert one window client coordinates to the "absolute" screen coordinates, you could then convert it to any other window client coordinates. But I still question the need for that...

I am sure one can find inconsistencies and inconveniences in Windows API, but I think this is not it.

[Paul McKenzie]

Originally posted by SteveS
ScreenToClient does not help because it returns a point who's coordinate system is based on the origin of the entire client area of the app.

From MSDN:

BOOL ScreenToClient(
HWND hWnd, // handle to window
LPPOINT lpPoint // screen coordinates
);

The function uses the window identified by the hWnd parameter and the screen coordinates given in the POINT structure to compute client coordinates. It then replaces the screen coordinates with the client coordinates. The new coordinates are relative to the upper-left corner of the specified window's client area.

There is no mention of the "app" as you noted. The coordinates returned are the coordinates relative to the HWND that you specify, in your case, the child window.

I need a point based on the upper-lefthand corner of the window being clicked upon. I don't understand why I'm failing to explain this simple thing...

Everyone understands what you want to do, and are trying to give you advice on how to solve it. Have you attempted to see what results you get if you took the advice, or is it just speculation? I have used these functions to map from one window's coordinates system to another, and this is the way most programs do it --

For your example:

a) Point in parent is (200, 200)
b) ClientToScreen(HWNDParent, &Points)
c) ScreenToClient(HWNDChild, &Points )

Points should be now (0.0)

I'm not programming in 16 bit Windows, I only meant that this is functionality that should have existed in the API since the days of Windows 3.11. If we have ClientToScreen, ScreenToClient, we must also have functions like ClientToWindow or ClientToChild.

There has never been such a "ClientToWindow" or WindowToClient function in Win 3.11. There is a GetWindowRect, but that's as close as you'll come to getting anything related to an entire window.

Regards,

Paul McKenzie

[Sam Hobbs]

Originally posted by SteveS
This is one of those roadblocks that the Windows API throws at you and I'm becoming increasingly annoyed at the gaping holes that exist in the API and their lack of interest in fixing these problems. I chouldn't have to write more than 1 line of code to get this value! I shouldn't have to reinvent the wheel! The API is supposed to handle these basic things and it is really annoying me how effing bad this API can be.

Sometimes people try harder to explain what they think the other person does not understand than trying to understand what they do not understand. So they get upset with the person for not listening but in fact it is they that are not listening. VladimirF answered your question but you did not make enough effort to understand it.

[aMarCruz]

After 10 years I have same problem.
The function is MapWindowPoints()
http://msdn.microsoft.com/en-us/libr.../dd145046.aspx

[OReubens]

This is one of those roadblocks that the Windows API throws at you and I'm becoming increasingly annoyed at the gaping holes that exist in the API and their lack of interest in fixing these problems. I chouldn't have to write more than 1 line of code to get this value! I shouldn't have to reinvent the wheel! The API is supposed to handle these basic things and it is really annoying me how effing bad this API can be.

If this is such a "gaping hole in the API"... Then it is truely amazing that thousands of working programs have been written using that windows API. It must be truely awesome programmmers that have managed to make those programs work despite the gaping holes.

Yes, I'm being sarcastic... THe fact is, there are no gaping holes, you just have failed to "see the light" in this issue.

Vladimir has explained the issue.
And he's right in asserting that there is very little reason ever to convert client coordinates of one window into client coordinates of another window. Chances are (like vladimir said) that you are doing something against the "commonly accepted practices" of dealing with Windows.

THere is no interest in fixing this, because thousands of programs in existance today proove that nothing needs fixing. YOu just need to learn to work WITH the API rather than against it.

[2kaud]

Ignore.