Qt Forum

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Unsolved

    Update: Forum Guidelines & Code of Conduct

    Solved Modal Dialogs break Virtual Keyboard

    General and Desktop
    2
    6
    620
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • D
      DalePennington last edited by

      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 ?

      Thanks,
      Dale Pennington

      Pl45m4 1 Reply Last reply Reply Quote 0
      • Pl45m4
        Pl45m4 @DalePennington last edited by

        @DalePennington

        Looks like

        • https://bugreports.qt.io/browse/QTBUG-56918

        If debugging is the process of removing software bugs, then programming must be the process of putting them in.

        ~E. W. Dijkstra

        1 Reply Last reply Reply Quote 0
        • D
          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.

          Dale

          1 Reply Last reply Reply Quote 0
          • D
            DalePennington last edited by

            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.

            Thanks,
            Dale

            D 1 Reply Last reply Reply Quote 0
            • D
              DalePennington @DalePennington last edited by

              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.

              D 1 Reply Last reply Reply Quote 0
              • D
                DalePennington @DalePennington last edited by

                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.

                1 Reply Last reply Reply Quote 3
                • First post
                  Last post