OnSizing not firing in dialog
-
I'm trying to handle the WM_SIZING message in my dialog, but for some reason, it's simply not firing when I resize the dialog. I added handlers for OnSize() and OnWindowPosChanging() as a sanity check, they both work fine, but for some reason OnSizing() is just never being called. I'm probably missing something really simple, but I just can't see what else there is to handling the message besides using the wizard to add the OnSizing function and ON_WM_SIZING() to the message map. Any ideas about why it isn't working? ----- In the land of the blind, the one eyed man is king.
Have you used Spy++ to verify that the
WM_SIZINGmessage is actually being sent?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
-
I'm trying to handle the WM_SIZING message in my dialog, but for some reason, it's simply not firing when I resize the dialog. I added handlers for OnSize() and OnWindowPosChanging() as a sanity check, they both work fine, but for some reason OnSizing() is just never being called. I'm probably missing something really simple, but I just can't see what else there is to handling the message besides using the wizard to add the OnSizing function and ON_WM_SIZING() to the message map. Any ideas about why it isn't working? ----- In the land of the blind, the one eyed man is king.
If the style of your dialog window is not set up correctly, then Windows will not send you the message - Windows will not interpret your window as being capable of resizing. A typical dialog frame does not allow resizing.
-
Have you used Spy++ to verify that the
WM_SIZINGmessage is actually being sent?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
Unfortunately, use of Spy++ causes my system to come to screeching halt. I even tried setting it up so that it would only capture the possible WM_SIZING message to that dialog to the same result. I use the finder tool to get my dialog, in the messages tab I select only WM_SIZING (though no matter what my settings are here the result is the same), and use the default output options ... immediately after hitting OK on this dialog, every open window stops responding except for a random couple - sometimes it is the spy tool, sometimes an explorer window, sometimes the MSDN library that stays active ... and I've even had the task manager window stop responding. This is with WinXP Pro. Weird, I've never had any problems with this computer (fresh install about 3-4 weeks ago), but SPY++ seems to rub it the wrong way or something. ----- In the land of the blind, the one eyed man is king.
-
If the style of your dialog window is not set up correctly, then Windows will not send you the message - Windows will not interpret your window as being capable of resizing. A typical dialog frame does not allow resizing.
It is setup with the "resizing" border style in the dialog properties window. It also resizes fine, and the WM_SIZE message comes through as expected, but the WM_SIZING message just never seems to happen. I dug around a bit more in the dialog and it's base classes, and found that the sizing isn't done entirely through the framework like I though it was. The sizing actually happens inside of a mouse move event which calls "SetWindowPos" when the left mouse is also down. I don't know exactly why this was done (it was done ages ago, long before I started working on it and the developer who did it is no longer here). Is this the likely culprit? Will a call to SetWindowPos to resize a frame cause the WM_SIZE and WM_WINDOWPOSCHANGING messages to come through as I'm seeing, but not WM_SIZING? That doesn't make much sense ... if WM_SIZE fires, WM_SIZING should as well. ----- In the land of the blind, the one eyed man is king.
-
Unfortunately, use of Spy++ causes my system to come to screeching halt. I even tried setting it up so that it would only capture the possible WM_SIZING message to that dialog to the same result. I use the finder tool to get my dialog, in the messages tab I select only WM_SIZING (though no matter what my settings are here the result is the same), and use the default output options ... immediately after hitting OK on this dialog, every open window stops responding except for a random couple - sometimes it is the spy tool, sometimes an explorer window, sometimes the MSDN library that stays active ... and I've even had the task manager window stop responding. This is with WinXP Pro. Weird, I've never had any problems with this computer (fresh install about 3-4 weeks ago), but SPY++ seems to rub it the wrong way or something. ----- In the land of the blind, the one eyed man is king.
Vineas wrote: Weird, I've never had any problems with this computer (fresh install about 3-4 weeks ago), but SPY++ seems to rub it the wrong way or something. That's rather disturbing... Is this just when trying to spy on your app, or does it happen with any app?
You must be careful in the forest Broken glass and rusty nails If you're to bring back something for us I have bullets for sale...
-
Vineas wrote: Weird, I've never had any problems with this computer (fresh install about 3-4 weeks ago), but SPY++ seems to rub it the wrong way or something. That's rather disturbing... Is this just when trying to spy on your app, or does it happen with any app?
You must be careful in the forest Broken glass and rusty nails If you're to bring back something for us I have bullets for sale...
-
Haven't tried anything else ... I suppose that might be interesting in itself. I'll have to try that tomorrow and drop a note in here as to the results. ----- In the land of the blind, the one eyed man is king.
Works on other apps, and found that it even works with this app if I'm not running in the debugger. So it only happens if I'm running in the debugger and try to spy it. This didn't happen at my last project, I've always done this with the app running in the debugger without problems. Anyway, on a related note, now that I've actually been able to Spy the dialog, the WM_SIZING message never does get sent, only the other ones that have handlers that work. ----- In the land of the blind, the one eyed man is king.
-
It is setup with the "resizing" border style in the dialog properties window. It also resizes fine, and the WM_SIZE message comes through as expected, but the WM_SIZING message just never seems to happen. I dug around a bit more in the dialog and it's base classes, and found that the sizing isn't done entirely through the framework like I though it was. The sizing actually happens inside of a mouse move event which calls "SetWindowPos" when the left mouse is also down. I don't know exactly why this was done (it was done ages ago, long before I started working on it and the developer who did it is no longer here). Is this the likely culprit? Will a call to SetWindowPos to resize a frame cause the WM_SIZE and WM_WINDOWPOSCHANGING messages to come through as I'm seeing, but not WM_SIZING? That doesn't make much sense ... if WM_SIZE fires, WM_SIZING should as well. ----- In the land of the blind, the one eyed man is king.
All I can think is that calling the SetWindowPos is more of a 'final' event than 'resizing' a window is, so there is no 'sizing' message only the 'here is the new size' message. If the mouse movement was cpatured for a different reason and the window's position was adjusted by Windows, instead of by the handler of the dialog itself, you would probably get all the messages you are expecting.
-
All I can think is that calling the SetWindowPos is more of a 'final' event than 'resizing' a window is, so there is no 'sizing' message only the 'here is the new size' message. If the mouse movement was cpatured for a different reason and the window's position was adjusted by Windows, instead of by the handler of the dialog itself, you would probably get all the messages you are expecting.
Yeah, as soon as I saw that, I was afraid that was the case. I'll have to see what I can do about removing this current way of sizing. From what I can tell of the code so far, the only reason it was done this way is so that the code can put a limit on how large the dialog gets ... which is perfectly handled in OnSizing (once I can get that event to happen anyway). Thanks. ----- In the land of the blind, the one eyed man is king.
-
Yeah, as soon as I saw that, I was afraid that was the case. I'll have to see what I can do about removing this current way of sizing. From what I can tell of the code so far, the only reason it was done this way is so that the code can put a limit on how large the dialog gets ... which is perfectly handled in OnSizing (once I can get that event to happen anyway). Thanks. ----- In the land of the blind, the one eyed man is king.
You should also see if you can receive the WM_MINMAXINFO message, which is where you are supposed to constrain the minimum and maximum size your window can get.