Solved

Coordinate hell

Posted on 1998-09-30
7
2,163 Views
Last Modified: 2013-11-20
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.
0
Comment
Question by:falkland
7 Comments
 
LVL 6

Expert Comment

by:thresher_shark
ID: 1322753
1) Yes (I think)
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 :-)
0
 

Expert Comment

by:umarama
ID: 1322754
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.



0
 
LVL 7

Accepted Solution

by:
psdavis earned 500 total points
ID: 1322755
> 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
0
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 
LVL 7

Expert Comment

by:psdavis
ID: 1322756
> 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
0
 
LVL 7

Expert Comment

by:psdavis
ID: 1322757
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



0
 

Author Comment

by:falkland
ID: 1322758
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.
0
 
LVL 7

Expert Comment

by:psdavis
ID: 1322759
You're truly welcome and thank you for the complement.

Phillip
0

Featured Post

6 Surprising Benefits of Threat Intelligence

All sorts of threat intelligence is available on the web. Intelligence you can learn from, and use to anticipate and prepare for future attacks.

Join & Write a Comment

Suggested Solutions

In this article, I'll describe -- and show pictures of -- some of the significant additions that have been made available to programmers in the MFC Feature Pack for Visual C++ 2008.  These same feature are in the MFC libraries that come with Visual …
Introduction: Database storage, where is the exe actually on the disc? Playing a game selected randomly (how to generate random numbers).  Error trapping with try..catch to help the code run even if something goes wrong. Continuing from the seve…
This video will show you how to get GIT to work in Eclipse.   It will walk you through how to install the EGit plugin in eclipse and how to checkout an existing repository.
Sending a Secure fax is easy with eFax Corporate (http://www.enterprise.efax.com). First, Just open a new email message.  In the To field, type your recipient's fax number @efaxsend.com. You can even send a secure international fax — just include t…

760 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

19 Experts available now in Live!

Get 1:1 Help Now