Solved Modal Dialogs break Virtual Keyboard
We have a virtual keyboard that has worked fine for all our other uses.
But when it is being used for a widget in a modal dialog box, the keyboard window displays, but no mouse events are delivered to it.
I have a test app with both modal and modeless dialogs, and shows the virtual keyboard behaving correctly with the modeless, but not with the modal.
Is there a magic setting I am missing to get the virtual keyboard to work with modal dialogs ?
Pl45m4 last edited by
DalePennington last edited by DalePennington
Yep, that looks like it to a "T".
Looks like they did some sort of hack to their QtVirtualKeyboard to make it work.
Now if I can somehow figure out how to apply that to my much simpler virtual keyboard.
OK , looking at the code changes it kinda makes sense. Something about making the Input Panel window the sibling to the "overlay", by using some code that looks like :
QQuickItem *pInputPanel; // The virtual keyboard panel QQuickItem *pInputItem; // The Focus Object pInputPanel->setParentItem(pInputItem->window()->contentItem());
The problem it that it is QML specific, and our input panel is widget based. Which leads to the question, if I have :
QDialog *pInputPanel; QObject *pInputItem;
What code do I use to get the equivalent effect. I have not used QML, but looking at the reference, setParentItem is not the same as setParent, and I do not have a good idea what the equivalent to QQuickWindow::contextItem would be.
After further review of the "Fix" for the QtVirtualKeyboard. As written it appears it would only work on QML based applications, as they dynamic cast the focus object to the QQuickItem. In a Widget based application, this would result in a null pointer.
So the question comes back to wether there is a Widget based equivalent fix.
After a lot more testing, and following some of the referenced bug reports, I found a workaround mentioned that works. The QWidget windowModality property controls what windows are affected when the specified widget is a modal window. By default it is ApplicationModal (all windows are affected). But if it is changed to WindowModal, then it only affects it parent, grandparent, and their sibling windows. So windows that do not have a parent (like the virtual keyboard input panel), or are far enough away in the window tree are will be usable.
Note that this means your dialog will need to have a proper parent (in the app I was working on, they were unparented originally), and if your application was complicated enough you might find windows you did not expect still being manipulable. But this should solve things in most cases.