Archived

This topic is now archived and is closed to further replies.

Window movement problems

This topic is 5279 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have a small game running in windowed mode. Everything works fine as long as the user doesn''t mess with the window If the window is minimized or obscured, then I get a WM_PAINT message which I handle to be able to redaw the window properly. This bit works fine. However, if the window is simply moved, I am not getting a WM_PAINT message, and I thought I was supposed to? It''s a puzzle game where the user clicks boxes to cycle colours and stuff and what is happening is that after the window has been moved, when you click on one of the boxes, it will redraw the new boxes at the old position! I implemented a temporary fix by handling the WM_MOVE message to do the same thing as WM_PAINT but I''m getting a squillion of those sent through as the mouse is moved which is obviously inefficient. So my questions are: 1. Am I supposed to be getting a WM_PAINT after the window has been moved? 2. As I supposed to continually get WM_MOVE messages while the window is being moved? 3. Is there one simple message that I will get AFTER a window has been moved so I can simply handle it once to update my coordinates correctly? Thanks, Caroline M.

Share this post


Link to post
Share on other sites
I do wonder about the method you''re using to draw the game. Are you using DirectDraw/D3D, or Windows GDI?

If GDI, then you should be working in client coordinates; those will automatically change when the window is moved.

If DirectDraw... then there''s something about changing the clipper, I think.

If Direct3D, perhaps Device::Reset() would help?

(Sorry, I''m not much of a DirectX person any more...)

Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3

Share this post


Link to post
Share on other sites
I''m using DirectDraw. The bit of code that does the work is:

mp_Primary->Blt(&m_CurrentBox, mp_Back, &source, DDBLT_WAIT, 0)

where mp_Primary is my primary surface, and m_CurrentBox is a rect that tells it what box it''s drawing. It''s this rect that is causing the problem as its coordinates are calculated based on the screen coordinates of the window and so when the window gets moved, it wasn''t getting updated.

Caroline M.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
1. depends. if a portion of the window needs to be redrawn, then yes, you will get a WM_PAINT for that portion. otherwise, no.

2. yes, almost always.

3. WM_EXITSIZEMOVE.

Share this post


Link to post
Share on other sites
I dont understand why you would need to paint in WM_MOVE. If some part of the window needs to be redrawn after a move, Windows will send a WM_PAINT message. Most of the time, however, Windows can simply move the contents of the window at the time of the move to another part of the screen. What happens if you don''t paint inside the WM_MOVE message?

Share this post


Link to post
Share on other sites
quote:
Original post by drslush
I dont understand why you would need to paint in WM_MOVE. If some part of the window needs to be redrawn after a move, Windows will send a WM_PAINT message. Most of the time, however, Windows can simply move the contents of the window at the time of the move to another part of the screen.
She is using DirectDraw in windowed mode. And if I am not mistaken, the primary buffer is the whole desktop. If her game only occupies a certain part of the desktop, she only needs to draw her game onto that part, not the whole desktop. When the window is moved, the coordinate where the game is drawn must also be moved to reflect the new window position.

Share this post


Link to post
Share on other sites
Thats exactly right Alnite. Whats happening is that if I dont repaint in the WM_MOVE, the next time I draw a box (the coordinates of which are calculated based on the screen coordinates of my window), the box is drawn relative to the old coordinates of the window, and not the new one.

And thanks AP, the WM_EXITSIZEMOVE did exactly what I wanted, problem fixed!

Share this post


Link to post
Share on other sites