In Qt 4.8.x Widget::grabMouse() does this on Windows:
void QWidget::grabMouse()
{
if (!qt_nograb()) {
if (mouseGrb)
mouseGrb->releaseMouse();
journalRec = SetWindowsHookEx(WH_JOURNALRECORD,
(HOOKPROC)qJournalRecordProc, GetModuleHandle(0), 0);
Q_ASSERT(testAttribute(Qt::WA_WState_Created));
SetCapture(effectiveWinId());
mouseGrb = this;
#ifndef QT_NO_CURSOR
mouseGrbCur = new QCursor(mouseGrb->cursor());
#endif
}
}
qJournalRecordProc is defined as:
// The procedure does nothing, but is required for mousegrabbing to work
#ifndef Q_WS_WINCE
LRESULT QT_WIN_CALLBACK qJournalRecordProc(int nCode, WPARAM wParam, LPARAM
lParam)
{
return CallNextHookEx(journalRec, nCode, wParam, lParam);
}
#endif //Q_WS_WINCE
I know that Qt 4.8.x is long out of support and Qt 5 does not do this
anymore, but...
WH_JOURNALRECORD hooks are subjected to various security requirements since
Vista or the SetWindowsHookEx call simply fails.
The thing is, that in some cases it does not fail, but messes up the
complete Desktop (until hook is removed by pressing Ctrl+Esc).
If the hook/unhook calls fail or are removed, applications that call
grabMouse still work without any noticeable issues.
Since this clearly a hack that was obviously needed to make mouse grabbing
working, I would very much like to know why it was done in this way and
what was the original problem.
I would be very grateful if someone could spare some time to answer my
question since this "issue" literally drove me nuts while debugging a
legacy application. To the point of tracing windows kernel side related to
the hooks.
Thanks a lot and a nice weekend,
Jaka
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
