falkland
asked on
Coordinate hell
My question has several components.
As I understand it, GetClientRect() will fill out a rect structure with the client coordinates for a given window. These returned values are in SCREEN COORDINATES? The origin is (0,0) because the area being returned is the total "client" area within the selected window with the upper left corner being (0,0)?
SCREEN COORDINATES are determined by (I suppose) monitor and adapter capabilities?
CLIENT COORDINATES are SCREEN COORDINATES?
SCREEN COORDINATES are pixels?
CLIENT COORDINATES are pixels?
DEVICE COORDINATES can be pixels?
DEVICE COORDINATES can be referred to as SCREEN COORDINATES?
DEVICE COORDINATES can be referred to as CLIENT COORDINATES?
ClientToScreen() simply updates your rect stucture making your client area relative to the entire screen area (1024X768 as a common example)? This is your window position for the most part (acknowledging the fact the the client area doesn't include certain aspects of the entire window).
So now I know my client area dimensions and its location on the screen?
What does the application of the MapDialogRect function have on the following example:
CRect rect;
GetClientRect(rect);
ClientToScreen(rect);
MapDialogRect(rect);
I do not fully understand the end results of this conversion.
Also, I mentioned earlier what I thought was the "client area" of a window. As I read through some literature I got some mixed signals on "client area". Basically, if you use an API call (as opposed to an MFC call) "client area" may be treated differently.
PS: Very little clear docs on this subject.
As I understand it, GetClientRect() will fill out a rect structure with the client coordinates for a given window. These returned values are in SCREEN COORDINATES? The origin is (0,0) because the area being returned is the total "client" area within the selected window with the upper left corner being (0,0)?
SCREEN COORDINATES are determined by (I suppose) monitor and adapter capabilities?
CLIENT COORDINATES are SCREEN COORDINATES?
SCREEN COORDINATES are pixels?
CLIENT COORDINATES are pixels?
DEVICE COORDINATES can be pixels?
DEVICE COORDINATES can be referred to as SCREEN COORDINATES?
DEVICE COORDINATES can be referred to as CLIENT COORDINATES?
ClientToScreen() simply updates your rect stucture making your client area relative to the entire screen area (1024X768 as a common example)? This is your window position for the most part (acknowledging the fact the the client area doesn't include certain aspects of the entire window).
So now I know my client area dimensions and its location on the screen?
What does the application of the MapDialogRect function have on the following example:
CRect rect;
GetClientRect(rect);
ClientToScreen(rect);
MapDialogRect(rect);
I do not fully understand the end results of this conversion.
Also, I mentioned earlier what I thought was the "client area" of a window. As I read through some literature I got some mixed signals on "client area". Basically, if you use an API call (as opposed to an MFC call) "client area" may be treated differently.
PS: Very little clear docs on this subject.
Hope this helps you in some way.
In my Dialog, I have a list ctrl with column 1 as dates. When the user presses Enter, I display the calendar control positioned just next to the item being selected.
I used ListCtrl.GetWindowRect() to get the position of my listctrl with the left top corner of my display monitor as the origin. SO THE GETWINDOWRECT gets the co-ordinates of a window in Pixels. I then used ScreenToClient() to corelate those co-ordinates to my client area, ie With the Dialog window treated as the client in which the listctrl resides, where is the listctrl located. Thus, I got the information that my listctrl is x pixels right of my dialog left, y pixels below the dialog top, etc. I then used GetItemRect() member of listctrl to get the items CLIENT position. Now, my item is not a window by itself. It is contained inside the listctrl window as a part of the listctrl. Hence GetItemRect told me by how much offset the item is inside the listctrl. (If I use ListCtrl.GetClientRect() it will give me the position of the listctrl window inside its client area which is it's own area. Hence ListCtrl.GetClientRect() will give 0,0,Width, Height in the CRect. But for that item, it's client area happens to be the listctrl area. Got it ??). Now, coming back to my example, I have determined my items offset w.r.t. it's client (listctrl), The listctrl's position w.r.t. to it's parent dialog. Adding the two, I have determined the position of my item rect as a client position of the dialog as though my item was embedded inside the dialog client area. With this information, I used ClientToScreen()to get the items screen position (Display monitor relative). I used this value to MoveWindow my Calendar Control which now shows up near the item.
If I have confused you further, please ignore this. I too had lots of doubt regarding this. With this example (used in my current project) I gained better insights into this.
In my Dialog, I have a list ctrl with column 1 as dates. When the user presses Enter, I display the calendar control positioned just next to the item being selected.
I used ListCtrl.GetWindowRect() to get the position of my listctrl with the left top corner of my display monitor as the origin. SO THE GETWINDOWRECT gets the co-ordinates of a window in Pixels. I then used ScreenToClient() to corelate those co-ordinates to my client area, ie With the Dialog window treated as the client in which the listctrl resides, where is the listctrl located. Thus, I got the information that my listctrl is x pixels right of my dialog left, y pixels below the dialog top, etc. I then used GetItemRect() member of listctrl to get the items CLIENT position. Now, my item is not a window by itself. It is contained inside the listctrl window as a part of the listctrl. Hence GetItemRect told me by how much offset the item is inside the listctrl. (If I use ListCtrl.GetClientRect() it will give me the position of the listctrl window inside its client area which is it's own area. Hence ListCtrl.GetClientRect() will give 0,0,Width, Height in the CRect. But for that item, it's client area happens to be the listctrl area. Got it ??). Now, coming back to my example, I have determined my items offset w.r.t. it's client (listctrl), The listctrl's position w.r.t. to it's parent dialog. Adding the two, I have determined the position of my item rect as a client position of the dialog as though my item was embedded inside the dialog client area. With this information, I used ClientToScreen()to get the items screen position (Display monitor relative). I used this value to MoveWindow my Calendar Control which now shows up near the item.
If I have confused you further, please ignore this. I too had lots of doubt regarding this. With this example (used in my current project) I gained better insights into this.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
> As I understand it, GetClientRect() will fill out a rect structure with the client coordinates for a given window. These returned values are in SCREEN COORDINATES?
1) OK, all coordinates are in pixels based on the top left hand corner.
> The origin is (0,0) because the area being returned is the total "client" area within the selected window with the upper left corner being (0,0)?
2) The most important rule to remember is: All buttons are windows. So when you get 'client' coordinates (such as GetClientRect) you are getting the size of the specific window. You should quickly notice that GetClientRect always returns 0,0 as the top most point and the width and the height of the specific control. RULE: GetClientRect is only to get the width and height of the specific window.
> SCREEN COORDINATES are determined by (I suppose) monitor and adapter capabilities?
3) Actually, not that specific. Just pixel position.
> CLIENT COORDINATES are SCREEN COORDINATES?
True.
> SCREEN COORDINATES are pixels?
True.
> CLIENT COORDINATES are pixels?
True. You're over thinking this... :)
> DEVICE COORDINATES can be pixels?
Actually, Device coordinates only play a part when you are doing DPtoLP and SetMapModes. Don't worry a bit about these yet. They're a whole 'nother bottle of worms.
> ClientToScreen() simply updates your rect stucture making your client area relative to the entire screen area (1024X768 as a common example)? This is your window position for the most part (acknowledging the fact the the client area doesn't include certain aspects of the entire window).
4) Right. Remember, when you got your GetClientRect, you only got the width and height of the specific control. Now ClientToScreen will only add the x and y pixel position of where the control was located to your rectangle. So for example, if you have a control located at position 285,210 on the screen and it was a button. GetClientRect will probably return something like (0,0,20,50) where 20 is your width and 50 is the height. ScreenToClient will just offset the entire thing by 285,210 or (285,210,305,260). Get it?
> So now I know my client area dimensions and its location on the screen?
Yep.
>What does the application of the MapDialogRect function have on the following example:
CRect rect;
GetClientRect(rect);
ClientToScreen(rect);
MapDialogRect(rect);
Now this is a completely different animal! Don't mix this concept here yet. If you really want to know this, repond back. Don't confuse the issue yet!
> Also, I mentioned earlier what I thought was the "client area" of a window. As I read through some literature I got some mixed signals on "client area". Basically, if you use an API call (as opposed to an MFC call) "client area" may be treated differently.
Client area is the area inside of your control. So if you wanted to draw at 10,10 in the button, it would draw inside the button. Non-client area is things like the border and the 'close' and 'minimize' buttons.
Phillip
1) OK, all coordinates are in pixels based on the top left hand corner.
> The origin is (0,0) because the area being returned is the total "client" area within the selected window with the upper left corner being (0,0)?
2) The most important rule to remember is: All buttons are windows. So when you get 'client' coordinates (such as GetClientRect) you are getting the size of the specific window. You should quickly notice that GetClientRect always returns 0,0 as the top most point and the width and the height of the specific control. RULE: GetClientRect is only to get the width and height of the specific window.
> SCREEN COORDINATES are determined by (I suppose) monitor and adapter capabilities?
3) Actually, not that specific. Just pixel position.
> CLIENT COORDINATES are SCREEN COORDINATES?
True.
> SCREEN COORDINATES are pixels?
True.
> CLIENT COORDINATES are pixels?
True. You're over thinking this... :)
> DEVICE COORDINATES can be pixels?
Actually, Device coordinates only play a part when you are doing DPtoLP and SetMapModes. Don't worry a bit about these yet. They're a whole 'nother bottle of worms.
> ClientToScreen() simply updates your rect stucture making your client area relative to the entire screen area (1024X768 as a common example)? This is your window position for the most part (acknowledging the fact the the client area doesn't include certain aspects of the entire window).
4) Right. Remember, when you got your GetClientRect, you only got the width and height of the specific control. Now ClientToScreen will only add the x and y pixel position of where the control was located to your rectangle. So for example, if you have a control located at position 285,210 on the screen and it was a button. GetClientRect will probably return something like (0,0,20,50) where 20 is your width and 50 is the height. ScreenToClient will just offset the entire thing by 285,210 or (285,210,305,260). Get it?
> So now I know my client area dimensions and its location on the screen?
Yep.
>What does the application of the MapDialogRect function have on the following example:
CRect rect;
GetClientRect(rect);
ClientToScreen(rect);
MapDialogRect(rect);
Now this is a completely different animal! Don't mix this concept here yet. If you really want to know this, repond back. Don't confuse the issue yet!
> Also, I mentioned earlier what I thought was the "client area" of a window. As I read through some literature I got some mixed signals on "client area". Basically, if you use an API call (as opposed to an MFC call) "client area" may be treated differently.
Client area is the area inside of your control. So if you wanted to draw at 10,10 in the button, it would draw inside the button. Non-client area is things like the border and the 'close' and 'minimize' buttons.
Phillip
OK, so I avoided an issue...
CRect rect;
GetClientRect(rect);
ClientToScreen(rect);
MapDialogRect(rect);
What I really see wrong here is that the MapDialogRect is converting the wrong type of coordinates. You use this function to convert the dialog-box units to screen units. Here, you have screen units and you're trying to map them to screen units. The code just doesn't seem to fit right. Here's a little documentation:
The MapDialogRect member function replaces the dialog-box units in lpRect with screen units (pixels) so that the rectangle can be used to create a dialog box or position a control within a box.
So, I'm confused why you would be getting the 'screen coordinates' of a window and trying to use them as dialog coordinates.
Phillip
CRect rect;
GetClientRect(rect);
ClientToScreen(rect);
MapDialogRect(rect);
What I really see wrong here is that the MapDialogRect is converting the wrong type of coordinates. You use this function to convert the dialog-box units to screen units. Here, you have screen units and you're trying to map them to screen units. The code just doesn't seem to fit right. Here's a little documentation:
The MapDialogRect member function replaces the dialog-box units in lpRect with screen units (pixels) so that the rectangle can be used to create a dialog box or position a control within a box.
So, I'm confused why you would be getting the 'screen coordinates' of a window and trying to use them as dialog coordinates.
Phillip
ASKER
Your coordinate explanation was excellent. I am glad that you took the time to explain (and indicate my overthinking). I wish I knew a little more about MapDialogRects purpose in life, but you accurately indicated that it is being used improperly in the example given. I hope others find this info useful.
You're truly welcome and thank you for the complement.
Phillip
Phillip
2) It is a function of what resolution the computer is running on (i.e. 800x600, 1280x1024, 640x480 <ick>).
3) I think client coordinates start at (0,0) within the dialog box/window at the upper left.
4) yes
5) yes
Gets even more fuzzy for me there :-)