Working around a WebBrowser ActiveX control resize bug of which you may or may not have been aware

  • Article

If you are hosting the WebBrowser ActiveX control in a native code application (perhaps following these instructions, then you may or may not have noticed that the control does not always resize correctly.  Specifically, if you maximize the application, then the same functions that will work properly to maximize any other child control (MoveWindow or SetWindowPos) won't always serve to maximize the WebBrowser control properly.  Even more specifically, what one might observe on certain pages (and I've found the MSDN homepage to be the foremost victim) is that although the control will maximize, it won't be repainted, or at least, not quickly--after a while it will eventually fully repaint itself at the new dimensions.  I tried lots of workarounds, including getting hold of the document itself and telling it to resize itself, and also this workaround for ActiveX control re-sizing: https://www.cherea.de/bitbucket/resizeaxctl/resizeaxctl.html.  What does work is simply instructing the control to repaint itself, this:

 

this->MoveWindow(area.left,area.top,area.Width(),area.Height(),FALSE);

this->RedrawWindow(area,NULL,RDW_UPDATENOW|RDW_ALLCHILDREN);