A bug with ActiveX components in the "Qt" borderless form

Inadvertently found a bug,qt5.1.1 official version of
First create a GUI project and drag into a Qaxwidget control (for ActiveX to take effect, you need to add config + = Qaxcontainer in the. Pro file)
Next, in order for ActiveX to work, you need to introduce a component that I introduced here is the IE component [CPP]View PlainCopy 

1. Mainwindow::mainwindow (Qwidget *parent):
2. Qmainwindow (parent),
3. UI (new Ui::mainwindow)
4. {
5. UI->SETUPUI (this);
6. Ui->axwidget->setcontrol ("{8856F961-340A-11D0-A96B-00C04FD705A2}");
7. }

Then you can start the test, generate EXE, run, the window is OK

The mouse clicks on the taskbar window, and the window is minimized, click Restore again, and change to this

Obviously, the window does not receive a drawing message when it is re-displayed, only the part of the ActiveX is displayed properly.
After an afternoon of debugging, the Discovery window did not receive the WM_PAINT message after receiving the wm_activate message
and normally it should be this order: wm_activate > WM_PAINT
The introduction of ActiveX after WM_PAINT is gone, this is the cause of the problem!

Knowing the cause of the problem is good, just forcing the window to redraw.
Overriding the Nativeevent method of the parent class in order to process Windows messages

[CPP]View PlainCopy 

2. BOOL Mainwindow::nativeevent (const qbytearray &eventtype, void *message, long *result)
4. {
6. PMSG msg = (PMSG) message;
8. if (msg->message = = Wm_activate && Msg->wparam = = wa_active)
10. {
12. //window is activated, Force redraw
14. InvalidateRect (HWND)This->winid (), nullptr, FALSE);
16. }
18. return false;
20. }

The fix is this bug:

https://bugreports.qt.io/browse/QTBUG-17548

http://blog.csdn.net/aqtata/article/details/17038105

A bug with ActiveX components in the "Qt" borderless form