custom controls
-
I have created a custom control to diaplay a rather compilcated bitmap on the main window. Now I can trap every message I need except for the WM_EXITSIZEMOVE, and this is probably the most important of them all. I only want to resize the bitmap after the user has finished resizing the main window. I can re-create the effect by sending a message to the control from the main window, but this defeats the purpose of having a custom control in the first place. Is there any way to detect when the parent window has completed a resize?
Waldermort
-
I have created a custom control to diaplay a rather compilcated bitmap on the main window. Now I can trap every message I need except for the WM_EXITSIZEMOVE, and this is probably the most important of them all. I only want to resize the bitmap after the user has finished resizing the main window. I can re-create the effect by sending a message to the control from the main window, but this defeats the purpose of having a custom control in the first place. Is there any way to detect when the parent window has completed a resize?
Waldermort
i've done this by waiting for a mouse button Up message. if you've received a bunch of WM_SIZE messages, then a WM_LBUTTONUP, you can assume the resize is done. or, if you haven't received a WM_SIZE msg in X seconds, you can assume the resize has stopped.
-
i've done this by waiting for a mouse button Up message. if you've received a bunch of WM_SIZE messages, then a WM_LBUTTONUP, you can assume the resize is done. or, if you haven't received a WM_SIZE msg in X seconds, you can assume the resize has stopped.
Could the solution have come any easier? What can I say, it's been a long day... Thanks for the answer :)
Waldermort
-
i've done this by waiting for a mouse button Up message. if you've received a bunch of WM_SIZE messages, then a WM_LBUTTONUP, you can assume the resize is done. or, if you haven't received a WM_SIZE msg in X seconds, you can assume the resize has stopped.
I'm probably missing something stupid, but I'm not getting any mouse messages whatsoever. I added the window using the resource editor specifying the 'custom' window and my own registered class. The 'enabled' and 'visible' flags are both set, so why can't I recieve any input?
Waldermort
-
I'm probably missing something stupid, but I'm not getting any mouse messages whatsoever. I added the window using the resource editor specifying the 'custom' window and my own registered class. The 'enabled' and 'visible' flags are both set, so why can't I recieve any input?
Waldermort
is any other control/window in your app doing a SetCapture ?
-
is any other control/window in your app doing a SetCapture ?
No, so far I only have a main window which does nothing except display my new custom control. I'm currently reading the articles on "custom controls" hoping to spot something I have missed, but they are all geared towards MFC which I'm not using.
Waldermort
-
No, so far I only have a main window which does nothing except display my new custom control. I'm currently reading the articles on "custom controls" hoping to spot something I have missed, but they are all geared towards MFC which I'm not using.
Waldermort
Do you have a WM_NCHITTEST handler that's indicating the cursor is in the NC area of the window? IOW, is it a client area/non-client area issue? WM_EXITSIZEMOVE should be sufficient if using the system resizing loop. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
Do you have a WM_NCHITTEST handler that's indicating the cursor is in the NC area of the window? IOW, is it a client area/non-client area issue? WM_EXITSIZEMOVE should be sufficient if using the system resizing loop. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
Yes, it was a NCHITTEST issue, I was returning the wrong value. Nomatter what I tried, I just cannot trap the WM_EXITSIZEMOVE. I am going to have to take Chris' approach and set a flag on a WM_SIZE event. But since I will only recieve mouse messages when the mouse is over the window I will have to use some type of timer. Luckily for me though, I have a thread running to monitor any changes required in the bitmap.
Waldermort
-
Yes, it was a NCHITTEST issue, I was returning the wrong value. Nomatter what I tried, I just cannot trap the WM_EXITSIZEMOVE. I am going to have to take Chris' approach and set a flag on a WM_SIZE event. But since I will only recieve mouse messages when the mouse is over the window I will have to use some type of timer. Luckily for me though, I have a thread running to monitor any changes required in the bitmap.
Waldermort
WalderMort wrote:
I will have to use some type of timer.
A timer? Really? Hmmm, ok. This doesn't seem like it should be necessary if all the hittest messages are handled properly. Between SetCapture(), TrackMouseEvent(), and WM_MOUSELEAVE there shouldn't be issues with the cursor moving outside the window. Are you doing your own modal resize loop or relying on the system one? It probably bugs you too, but timers in these situations are an extreme, last-resort, cheesy solution IMO :) Mark
Mark Salsbery Microsoft MVP - Visual C++ :java: