Get client area without borders

Hi List244,

I'm not sure if I understand - the rect returned by GetClientRect() always returns the rectangle of the window's client area with 0, 0 as the top/left point.

So I guess the problem is how you monitor the pixel at 10, 10 - IMO you need a DC for the client area of the window - this is returned by GetDC().

Maybe you should post some code so we could see what the problem is ...

ZOPPO

Sorry abel - you were faster ...

It should be

HDC hDC = ::GetDC( hWnd );
COLORREF cref = ::GetPixel( hDC, 10, 10 );

I am basically looking for some sort of translate.. Firstly, I have a color-picker. This color-picker grabs a color off the screen and gets a pixel position. This is how I find the static position (10,10). How this color picker works is it uses GetWindowRect and gets the DC of desktop. It then gets the current mouse coords and subtracts the left/top from the rect. This gives me the current position in the window of the pixel under the mouse.

However, when I go back to check this position (10,10), it is no longer returning the same position since getpixel is ignoring borders and the previous method of subtracting the rect is not.

It is easier to use GetPixel and GetWindowDC on the desktop window, because GetPixel is free of the current window and the desktop window is borderless you don't have offset problems. Then they'll work. I saw that technique in this code: http://www.codeguru.com/vb/gen/vb_graphics/article.php/c2357

I am assuming that my problem is borders, but I will explain my problem:

I use GetDC on the desktop. I then get the current window (WindowFromPoint) and subtract the top-left. This gives me my pixel location in the current window.

I then take what I get from that to another application. It again uses GetDC on the desktop. Then, it adds the top-left of the window to the static (10,10), or whatever the pixels may be. But, when I do this , I am getting two different pixels.

I need to be able to use one program to grab a pixel and it's location, and I need to take that to my other program which is needs to find that pixel and monitor it.

Remove the part where you do a WindowFromPoint. The GetPixel works fine with only the desktop DC, regardless the windows on top of it. In fact, you should not need any offset calculations at all.

Well, the reason I am doing that is to get the coord in the app for my other application. Because if I just get the point... I don't know that when my other app runs that it will be in the same spot.

Should I replace that with ScreenToClient on the WindowFromPoint? Rather than subtracting top-left?

Here is an update with more specifics:

ScreenToClient(WindowFromPoint(*Mouse),Mouse); //Mouse is an LPPOINT

That is how the original X,Y are grabbed(489,469)

Then the following is done:

POINT Pos;
Pos.x = 489;
Pos.y = 469;
ClientToScreen(WinHandle,&Pos); //WinHandle is a known handle to the window in question

Now I get: 1184,673.

I use SetCursorPos(Pos.x,Pos.y)

Now, it sets the cursor to the wrong position. It is not the position I wanted it at. Also, when I return to the color picker, it tells me that the position it set it to is:

(487,438)


Maybe now that I have included the code someone can help me out.

I'd love to help you out, but something tells me that I'm not certain about what you are doing. Let me try to put it in my words, and perhaps you can tell me whether I am correct or not.

1. Get the color under the mouse pointer, regardless under what window or process
    
2. Run another program, which monitors this pixel
    
3. If the window where the pixel was found, moves, the relative position should be used of that window. 

Btw: I have no idea what SetCursorPos does in this thread, is that some other requirement, moving the mouse pointer? Let's focus on the monitoring bit first... ;)

Abel, SetCursorPos is a test. It is my way of seeing what the program is doing. It is not working, I know this, so I added that to see where the program is trying to monitor vs. where I wanted it to. And in doing so I found that it is actually a bit off from the pixel I wanted it to monitor.

Abel, not quite. Here is the best way I can explain it:

Say you have a 3rd party app which has a circle in the corner of the app. This circle changes colors depending on the status. This color is a code which has meaning. Let's say red is an error, black is a slow-down, and green means it is running good. So, I make a color-picker, this application's sole purpose is so that I can find the position of this circle, or at least, a pixel in the circle. I take this coord, and I take it to my REAL application, the one I am developing. And I use this application to monitor that circle... if GetPixel returns Red, it notes the error, black, it notes the slow-down, green, it does nothing.

Now, my problem is the pixel I am getting from the picker is not matching up with the pixel the real application is grabbing.

I've tried to fix this most recently by using ScreenToClient and ClientToScreen. I got the pixel with the color picker by getting the general cursor pos and using ScreenToClient. This gave me the pixel at 489,469. I took that number to the real app and did ClientToScreen. This failed to grab the correct pixel. So to test it, I set the cursor position. It set it a bit off from where I wanted.

So my problem is.. how do I get the cursor position relative to a window, and then save that so that I can get that position relative to that window at any time?

Ok, that makes sense. Am I correct in saying that the circle is relative to a certain windows topleft corner? In other words, you will need the window position containing that circle and find the pixel relative to that top left corner. And monitor that.

Yes.

Anyone have ideas?

I got it working:

I was using:

GetCursorPos
ScreenToClient(WindowFromPoint,Pos)
ClientToScreen(WindowFromPoint,Pos)

It was not working correctly. I changed it to:

GetCursorPos
WIN = WindowFromPoint
ScreenToClient(WIN,Pos)
ClientToScreen(WIN,Pos)

This fixed it. Apparently somehow, even though the application was not changing, it was not liking the recall to getting the HWND.