Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. Mobile and Embedded
  4. [SOLVED] QLineEdit does not receive character input on Android
Forum Updated to NodeBB v4.3 + New Features

[SOLVED] QLineEdit does not receive character input on Android

Scheduled Pinned Locked Moved Mobile and Embedded
androidkeyboardqlineedit
30 Posts 3 Posters 15.5k Views 2 Watching
  • 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.
  • T tarod.net
    2 Jun 2015, 07:37

    @SteveMBay Sorry, Steve, but I don't understand well the situation.

    • When you say "background", you mean another window which is showing your MctMainDialog class?
    • The widget you mention, is the MctMainDialog class you showed some days ago?
    • You say the widget won't disappear after you touch the surrounding area, but if you detect a touching event, you could hide the widget or window using the functions provided by Qt, couldn't you?
    S Offline
    S Offline
    SteveMBay
    wrote on 2 Jun 2015, 08:30 last edited by
    #21

    @tarod.net Sorry, my English isn't the best.

    • Yes, the "background" is a main window (my application is a text editor) and this widget is like a dropdown menu, where I can setup many things.
    • Yes, we are talking the same widget that was QDialog before, but I recreated and now it is a QWidget. (Now called MctWidget, and yes, the name was misleading, it was "main" because it had some child dialogs as well.)
    • Maybe :) My (really) main window contains a tool handler object which owns the formatting and configuring dialogs and widgets.

    Now I am trying :

    1. to override focusInEvent() on this ReallyMainWindow
    2. focusInEvent() emits a signal that connected to ToolHandler
    3. ToolHandler gets a new slot: where calls this->mctWidget->hide()
    S 1 Reply Last reply 2 Jun 2015, 08:35
    0
    • S SteveMBay
      2 Jun 2015, 08:30

      @tarod.net Sorry, my English isn't the best.

      • Yes, the "background" is a main window (my application is a text editor) and this widget is like a dropdown menu, where I can setup many things.
      • Yes, we are talking the same widget that was QDialog before, but I recreated and now it is a QWidget. (Now called MctWidget, and yes, the name was misleading, it was "main" because it had some child dialogs as well.)
      • Maybe :) My (really) main window contains a tool handler object which owns the formatting and configuring dialogs and widgets.

      Now I am trying :

      1. to override focusInEvent() on this ReallyMainWindow
      2. focusInEvent() emits a signal that connected to ToolHandler
      3. ToolHandler gets a new slot: where calls this->mctWidget->hide()
      S Offline
      S Offline
      SteveMBay
      wrote on 2 Jun 2015, 08:35 last edited by
      #22

      @SteveMBay In theory, this should work, but ReallyMainWindow's focusInEvent() never called... :(

      T 1 Reply Last reply 2 Jun 2015, 11:30
      0
      • S SteveMBay
        2 Jun 2015, 08:35

        @SteveMBay In theory, this should work, but ReallyMainWindow's focusInEvent() never called... :(

        T Offline
        T Offline
        tarod.net
        wrote on 2 Jun 2015, 11:30 last edited by tarod.net 6 Feb 2015, 11:31
        #23

        @SteveMBay Thank you for your answers! :)

        Why don't you set MctWidget as modal

        setWindowModality(Qt::WindowModal);

        and add a button to close this child window?

        If you implement that, MctWidget will remain opened until the user clicks the close button, but you will have more control to avoid wrong behaviours.

        The line this->setWindowFlags(Qt::Popup| Qt::FramelessWindowHint); should be removed if you like the idea.

        About focusInEvent, try with this instead:

        bool ReallyMainWindow::event(QEvent *e) {
        {
            if (e->type() == QEvent::WindowActivate) {
                // window was activated
            }
            return QWidget::event(e);
        }
        

        "Individually, we are one drop. Together, we are an ocean."

        S 1 Reply Last reply 2 Jun 2015, 12:27
        1
        • T tarod.net
          2 Jun 2015, 11:30

          @SteveMBay Thank you for your answers! :)

          Why don't you set MctWidget as modal

          setWindowModality(Qt::WindowModal);

          and add a button to close this child window?

          If you implement that, MctWidget will remain opened until the user clicks the close button, but you will have more control to avoid wrong behaviours.

          The line this->setWindowFlags(Qt::Popup| Qt::FramelessWindowHint); should be removed if you like the idea.

          About focusInEvent, try with this instead:

          bool ReallyMainWindow::event(QEvent *e) {
          {
              if (e->type() == QEvent::WindowActivate) {
                  // window was activated
              }
              return QWidget::event(e);
          }
          
          S Offline
          S Offline
          SteveMBay
          wrote on 2 Jun 2015, 12:27 last edited by
          #24

          @tarod.net The Modal window does the trick! Now this works fine! Thank you!

          It's so easy solution...

          (Otherwise, I don't understand why Qt::Popup prevented to get input. Is this a bug or a feature?)

          (About ReallyMainWindow... i found that other view catches the input instead of RMW, and I didn't modify the code so deep, so this was a dead end as well)

          T 1 Reply Last reply 2 Jun 2015, 12:36
          0
          • S SteveMBay
            2 Jun 2015, 12:27

            @tarod.net The Modal window does the trick! Now this works fine! Thank you!

            It's so easy solution...

            (Otherwise, I don't understand why Qt::Popup prevented to get input. Is this a bug or a feature?)

            (About ReallyMainWindow... i found that other view catches the input instead of RMW, and I didn't modify the code so deep, so this was a dead end as well)

            T Offline
            T Offline
            tarod.net
            wrote on 2 Jun 2015, 12:36 last edited by
            #25

            @SteveMBay When you say that other view catches the input, do you mean other subwindows or child windows which you are using to setup your main window?

            In my opinion, it's the same case, and I think you should apply the same solution setting the window modality as Qt::WindowModal.

            "Individually, we are one drop. Together, we are an ocean."

            S 1 Reply Last reply 3 Jun 2015, 06:52
            0
            • T tarod.net
              2 Jun 2015, 12:36

              @SteveMBay When you say that other view catches the input, do you mean other subwindows or child windows which you are using to setup your main window?

              In my opinion, it's the same case, and I think you should apply the same solution setting the window modality as Qt::WindowModal.

              S Offline
              S Offline
              SteveMBay
              wrote on 3 Jun 2015, 06:52 last edited by
              #26

              @tarod.net It isn't so important, but I can explain it.

              Other views are the surrounding and background objects on the screen (such as toolbar and docview).

              ReallyMainWindow class is just a container, it does not implements the event handling. To be honest, the main structure is not my task and I am not really familiar with the deep details. As far as I see, there are more surface object where the input (touch) can be caught.

               +---ReallyMAinWindow----+
               | toolbar               |
               +-------------+-----+---+
               |             | MCT |   |
               |             +-----+   |
               |    docview            |
               |                       |
               +-----------------------+
              
              T 1 Reply Last reply 3 Jun 2015, 07:50
              0
              • S SteveMBay
                3 Jun 2015, 06:52

                @tarod.net It isn't so important, but I can explain it.

                Other views are the surrounding and background objects on the screen (such as toolbar and docview).

                ReallyMainWindow class is just a container, it does not implements the event handling. To be honest, the main structure is not my task and I am not really familiar with the deep details. As far as I see, there are more surface object where the input (touch) can be caught.

                 +---ReallyMAinWindow----+
                 | toolbar               |
                 +-------------+-----+---+
                 |             | MCT |   |
                 |             +-----+   |
                 |    docview            |
                 |                       |
                 +-----------------------+
                
                T Offline
                T Offline
                tarod.net
                wrote on 3 Jun 2015, 07:50 last edited by
                #27

                @SteveMBay As far as I see, ReallyMainWindow wouldn't need to get the inputs. They are needed for the toolbar, MCT and docview, right?

                "Individually, we are one drop. Together, we are an ocean."

                S 1 Reply Last reply 3 Jun 2015, 08:08
                0
                • T tarod.net
                  3 Jun 2015, 07:50

                  @SteveMBay As far as I see, ReallyMainWindow wouldn't need to get the inputs. They are needed for the toolbar, MCT and docview, right?

                  S Offline
                  S Offline
                  SteveMBay
                  wrote on 3 Jun 2015, 08:08 last edited by
                  #28

                  @tarod.net Yes, that's right.
                  A bit confused me that RMW's base is inherited from QWidget. :) So, technically it's able to get input. But it shouldn't, as you say.

                  T 1 Reply Last reply 3 Jun 2015, 08:45
                  0
                  • S SteveMBay
                    3 Jun 2015, 08:08

                    @tarod.net Yes, that's right.
                    A bit confused me that RMW's base is inherited from QWidget. :) So, technically it's able to get input. But it shouldn't, as you say.

                    T Offline
                    T Offline
                    tarod.net
                    wrote on 3 Jun 2015, 08:45 last edited by
                    #29

                    @SteveMBay Just for clarification, did you fix the wrong behaviours or do you need more help about this issue?

                    "Individually, we are one drop. Together, we are an ocean."

                    1 Reply Last reply
                    0
                    • T Offline
                      T Offline
                      tataeress
                      wrote on 17 Feb 2021, 03:50 last edited by
                      #30

                      a solution i found is to remove only the Qt::Sheet flag and you can let the other Qt::FramelessWindowHint and Qt::Popup with no problem

                      1 Reply Last reply
                      0

                      • Login

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • Users
                      • Groups
                      • Search
                      • Get Qt Extensions
                      • Unsolved