Home/ Questions/Q 6778159
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T16:14:02+00:00

This happens with all ActiveX controls. If I reposition an ActiveX control with DeferWindowPos

  • 0

This happens with all ActiveX controls. If I reposition an ActiveX control with DeferWindowPos

HDWP hdwp = BeginDeferWindowPos(1);
DeferWindowPos(hdwp, m_pActiveX->GetSafeHwnd(), NULL, left, top, width, height, SWP_NOZORDER);
EndDeferWindowPos(hdwp);

it goes there but then moves/resizes to its old rectangle once you click anywhere inside the control. If I use MoveWindow instead 

m_pActiveX->MoveWindow(left, top, width, height);

this doesn’t happen.

It doesn’t happen with any other type of control, only with ActiveX controls, but it happens with all of them. I made a test to confirm this, creating a new ActiveX control project and didn’t make any changes, and the problem was still there.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You never got an appropriate answer. I’ll try to help out a bit here.

    The issue is that MFC hides a lot of the trickiness with hosting an ActiveX control within it’s framework. Specifically, if you step into the MoveWindow call, it is not simply a wrapper around the Win32 MoveWindow function. It calls into the OLE Control Container support classes. This basically says, if we have a control site interface, then call COleControlSite::MoveWindow, otherwise call the standard Win32 MoveWindow. The same occurs with several other window functions handled by CWnd etc. For example COleControlSite::SetWindowPos handles hiding/showing the control, then calls COleControlSite::MoveWindow to move it, and then finally calls ::SetWindowPos (with the move/show flags masked out) to handle the rest.

    Once within COleControlSite::MoveWindow, you will notice it does several things: it calls SetExtent, updates it’s internal m_rect member, and then calls SetObjectRects.

    Bypassing these for ActiveX controls using the Win32 API directly (eg via DeferWindowPos) causes some of these crucial steps to be missed. Depending on how your code is layed out, usually you can handle this yourself.

    • 0