Check the documentation which says:
Quote
The low-order word specifies the x-coordinate of the cursor. The coordinate is relative to the upper-left corner of the client area.
The high-order word specifies the y-coordinate of the cursor. The coordinate is relative to the upper-left corner of the client area.

Remarks
Use the following code to obtain the horizontal and vertical position:
xPos = GET_X_LPARAM(lParam);
yPos = GET_Y_LPARAM(lParam);

Important Do not use the LOWORD or HIWORD macros to extract the x- and y- coordinates of the cursor position because these macros return incorrect results on systems with multiple monitors. Systems with multiple monitors can have negative x- and y- coordinates, and LOWORD and HIWORD treat the coordinates as unsigned quantities.

Note the "Important" section. You are using those macros.

If you use the GET_X_LPARAM and GET_Y_LPARAM macros it will be the coordinate relative to the upper-left corner of the client area.

looks like frob found your problem back on the 28th.

also looks like i should mod my code to support multiple monitors!

x=(short)LOWORD(lParam)
it shoud be:
mousex=(lParam & 0x0000FFFF);

for y, you do:
y=(short)HIWORD(lParam);
it should be:
mousey=(lParam >> 16);

I tried the above code but I am still getting the same result. I also tried your message pump.

Wrong: The LOWORD and HIWORD macros

Right: The GET_X_LPARAM and GET_Y_LPARAM are 100% ok. You should really use them.

@Norman Barrows:

Your cast assumes that mouse coordinates are always positive. Which they are not (think of SetCapture).

@Phil67rpg:

You really really need to describe your problem better. Also, how do you determine that it's a problem.

"I think the mouse is not working properly" is not a good description. All it tells us is that something is not what you expect it to be.

Edit: Fixed the wrong macros, I actually did mean the GET_X_LPARAM and GET_Y_LPARAM macros.

The LOWORD and HIWORD macros are 100% ok. You should really use them.

As frob mentioned, no, you should use GET_X_LPARAM() and GET_Y_LPARAM().

As for the actual topic, I strongly suggest you put no effort into it.

Enough evidence has been put forth to suggest that phil67rpg is just a troll (and trust me, so many people tried to tell me he was for a long time while I continued doing my best to give him the benefit of a doubt), but even if he isn’t he has shown no willingness to put forth any demonstrable effort of his own, not only in his code but in the way he asks posts questions the fact that he has some problem somewhere of some kind.

I’ve strongly reprimanded him for his posting style after which he changed for approximately 2 posts before returning back to his old ways.

This, combined with the fact that every single time you provide a full and complete answer, he replies with code even more mangled and confounding than anything you have just suggested to him, confirms that he has no capacity to learn in any way, assuming he is not a troll in the first place (major earthquake shaking my building right now, have to go).

L. Spiro

well I am not a troll and yes I am trying my best but I think spiro has very high standards

It is what I suspected from the start, namely a common beginner pitfall: He uses the same dimension for the windows creation and for the D3D backbuffer. But for the latter one must use the client area of the window, e.g. optainable using GetClientRect.

also sounds like you're running in windowed mode, and the difference between the size of the window, and the client area (the part inside the border that you draw in) might be giving you issues.

well If anybody cares, the reason I was getting problems was because my compiler was not working properly, it was not compiling new code.sorry about this.