Resizing a window
-
I'm writing a plug-in for an NLE, and I wish to forcibly resize my window to fill the area that is available. The PlugInPP class is defined as such:
class ATL_NO_VTABLE CPluginPP :
public CComObjectRootEx<CComMultiThreadModel>,
public CComCoClass<CPluginPP, &CLSID_PluginPP>,
public IPropertyPageImpl<CPluginPP>,
public CDialogImpl<CPluginPP>In order to get the sizing messages for the parent window, I have sub-classed it, and when I see a WM_SIZE message, I do the following:
::MoveWindow( Main_zMappingArray[ 0 ].hDialogWnd,
0,
0,
LOWORD( lParam ),
HIWORD( lParam ),
TRUE );My PlugInPP::OnSize method gets called with the new size, no problem there. However, there is immediately another WM_SIZE message setting back the original sizes or the dialog resource. I'm beginning to think that the silly buggers have subclassed the PlugInPP window and resize it whenever they see a WM_SIZE message, but that seems like an awful lot of work to do in a situation where the window is by no means resize-able. Give the ATL::CDialogIMpl and ATL::IPropertyPageImpl base classes, I'm wondering if there's a trick to resizing them, or a trick to preventing them from being resized that I can opt out of. Otherwise, I guess I'm stuck with subclassing my own window again, and just eating the WM_SIZE messages, and hope that works.
CraigL
-
I'm writing a plug-in for an NLE, and I wish to forcibly resize my window to fill the area that is available. The PlugInPP class is defined as such:
class ATL_NO_VTABLE CPluginPP :
public CComObjectRootEx<CComMultiThreadModel>,
public CComCoClass<CPluginPP, &CLSID_PluginPP>,
public IPropertyPageImpl<CPluginPP>,
public CDialogImpl<CPluginPP>In order to get the sizing messages for the parent window, I have sub-classed it, and when I see a WM_SIZE message, I do the following:
::MoveWindow( Main_zMappingArray[ 0 ].hDialogWnd,
0,
0,
LOWORD( lParam ),
HIWORD( lParam ),
TRUE );My PlugInPP::OnSize method gets called with the new size, no problem there. However, there is immediately another WM_SIZE message setting back the original sizes or the dialog resource. I'm beginning to think that the silly buggers have subclassed the PlugInPP window and resize it whenever they see a WM_SIZE message, but that seems like an awful lot of work to do in a situation where the window is by no means resize-able. Give the ATL::CDialogIMpl and ATL::IPropertyPageImpl base classes, I'm wondering if there's a trick to resizing them, or a trick to preventing them from being resized that I can opt out of. Otherwise, I guess I'm stuck with subclassing my own window again, and just eating the WM_SIZE messages, and hope that works.
CraigL
Hoping someone can still provide some help here, this is some update on what I've been finding; but one Q at a time so it doesn't seem so haphazard. When I subclass the propertypage/dialog, the previous proc address I get is an address well within the range that the Modules tab in VSW shows me user32.dll was loaded, so from that I can be fairly certain that the containing application is NOT subclassing it and simply re-initiating a MoveWindow whenever it sees a specific message. Is this correct? Or if it is not a safe assumption, any pointers on where/how to figure out who all is busy subclassing and 'walk the tree'? Thanks,
CraigL
-
I'm writing a plug-in for an NLE, and I wish to forcibly resize my window to fill the area that is available. The PlugInPP class is defined as such:
class ATL_NO_VTABLE CPluginPP :
public CComObjectRootEx<CComMultiThreadModel>,
public CComCoClass<CPluginPP, &CLSID_PluginPP>,
public IPropertyPageImpl<CPluginPP>,
public CDialogImpl<CPluginPP>In order to get the sizing messages for the parent window, I have sub-classed it, and when I see a WM_SIZE message, I do the following:
::MoveWindow( Main_zMappingArray[ 0 ].hDialogWnd,
0,
0,
LOWORD( lParam ),
HIWORD( lParam ),
TRUE );My PlugInPP::OnSize method gets called with the new size, no problem there. However, there is immediately another WM_SIZE message setting back the original sizes or the dialog resource. I'm beginning to think that the silly buggers have subclassed the PlugInPP window and resize it whenever they see a WM_SIZE message, but that seems like an awful lot of work to do in a situation where the window is by no means resize-able. Give the ATL::CDialogIMpl and ATL::IPropertyPageImpl base classes, I'm wondering if there's a trick to resizing them, or a trick to preventing them from being resized that I can opt out of. Otherwise, I guess I'm stuck with subclassing my own window again, and just eating the WM_SIZE messages, and hope that works.
CraigL
Well, I did finally manage to figure it out. The containing app was moving it, but using the
IPropertyPageImpl::Movemethod. Why they didn't see fit to call itMoveWindowlike every other single thing in windows, is beyond me. If I'd been able to figure out how to configure a breakpoint for whenever my DLL was entered, I'd have found it in no time.CraigL
-
Well, I did finally manage to figure it out. The containing app was moving it, but using the
IPropertyPageImpl::Movemethod. Why they didn't see fit to call itMoveWindowlike every other single thing in windows, is beyond me. If I'd been able to figure out how to configure a breakpoint for whenever my DLL was entered, I'd have found it in no time.CraigL
Craig Longman wrote:
If I'd been able to figure out how to configure a breakpoint for whenever my DLL was entered, I'd have found it in no time.
Well, you can temporarily insert DebugBreak() into the code next time...
-
Craig Longman wrote:
If I'd been able to figure out how to configure a breakpoint for whenever my DLL was entered, I'd have found it in no time.
Well, you can temporarily insert DebugBreak() into the code next time...
Thanks, but that actually wouldn't have helped. The point was I didn't know where the host app was calling in. So, short of adding in a call like that to every method, as well as every method of every base class, there was no solution that I could program in. Breaking on MyDLL.dll!* is pretty much the only solution. Even the Class::* didn't work, as the parser failed to find some of the templatized based classes. Again, manually going through each and every base and adding breakpoints in would have caught them for each class that I tediously added them all in, but I was really hoping to get a better idea of when anything was called by the host app.