Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Change focusOutEvent
Forum Updated to NodeBB v4.3 + New Features

Change focusOutEvent

Scheduled Pinned Locked Moved Solved General and Desktop
31 Posts 4 Posters 4.6k 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.
  • JonBJ JonB

    @Vlad02
    I don't think it will be a QTableWidgetItem because that is not a QWidget or even a QObject. If you need to find the parent, I think you are doing editing (and only editing), take a look at parameter to
    QWidget *QStyledItemDelegate::createEditor(QWidget *parent, const QStyleOptionViewItem &option, const QModelIndex &index) const. I thought it would be the QTableWidget, but you say not. You'll have to do some digging.

    V Offline
    V Offline
    Vlad02
    wrote on last edited by Vlad02
    #20

    @JonB
    I tried to print the following inside the createEditor:

    qDebug() << parent->parent();
    qDebug() << editor->parent();
    

    As a result, I got this:
    MyTable(0x7aace8)
    QWidget(0x7a3188, name = "qt_scrollarea_viewport")
    I don't really understand what qt_scrollarea_viewport is.

    If I use

    CustomLineEdit *editor = new CustomLineEdit(old_str, parent);
    

    I get the following cell editing (as I need):
    b8985fcf-9101-458f-9d95-ac9ae4040e71-image.png

    If I try it this way

    CustomLineEdit *editor = new CustomLineEdit(old_str, parent->parentWidget());
    

    then the result is as follows:
    4106100a-a04b-46c8-9cd7-9c8a52cb56fb-image.png

    JonBJ 1 Reply Last reply
    0
    • V Vlad02

      @JonB
      I tried to print the following inside the createEditor:

      qDebug() << parent->parent();
      qDebug() << editor->parent();
      

      As a result, I got this:
      MyTable(0x7aace8)
      QWidget(0x7a3188, name = "qt_scrollarea_viewport")
      I don't really understand what qt_scrollarea_viewport is.

      If I use

      CustomLineEdit *editor = new CustomLineEdit(old_str, parent);
      

      I get the following cell editing (as I need):
      b8985fcf-9101-458f-9d95-ac9ae4040e71-image.png

      If I try it this way

      CustomLineEdit *editor = new CustomLineEdit(old_str, parent->parentWidget());
      

      then the result is as follows:
      4106100a-a04b-46c8-9cd7-9c8a52cb56fb-image.png

      JonBJ Online
      JonBJ Online
      JonB
      wrote on last edited by
      #21

      @Vlad02
      The table widget will have a QScrollArea. That will have a viewport, QWidget *QAbstractScrollArea::viewport() const. It looks like that is the parent of the edit widget. Maybe that is what grabs the Tabs. I don't know where that leaves you with regard to eventFilter().

      You never gave a complete, minimal example. I take it you are saying you have a QLineEdit-derived widget for editing only in a QTableWidget, and there you cannot deal with Tab, and that's the whole thing.

      V 1 Reply Last reply
      0
      • JonBJ JonB

        @Vlad02
        The table widget will have a QScrollArea. That will have a viewport, QWidget *QAbstractScrollArea::viewport() const. It looks like that is the parent of the edit widget. Maybe that is what grabs the Tabs. I don't know where that leaves you with regard to eventFilter().

        You never gave a complete, minimal example. I take it you are saying you have a QLineEdit-derived widget for editing only in a QTableWidget, and there you cannot deal with Tab, and that's the whole thing.

        V Offline
        V Offline
        Vlad02
        wrote on last edited by
        #22

        @JonB said in Change focusOutEvent:

        I take it you are saying you have a QLineEdit-derived widget for editing only in a QTableWidget, and there you cannot deal with Tab, and that's the whole thing.

        That's right. I can provide the code of the derived class if necessary.

        I tried to look at the parent hierarchy of my LineEdit and got the following:

        QWidget(0x2ef34a8, name="qt_scrollarea_viewport")
        MyTable(0x2efa8f8)
        QWidget(0x14094b0, name="centralWidget")
        MainWindow(0x61fde0, name="MainWindow")

        JonBJ 1 Reply Last reply
        0
        • V Vlad02

          @JonB said in Change focusOutEvent:

          I take it you are saying you have a QLineEdit-derived widget for editing only in a QTableWidget, and there you cannot deal with Tab, and that's the whole thing.

          That's right. I can provide the code of the derived class if necessary.

          I tried to look at the parent hierarchy of my LineEdit and got the following:

          QWidget(0x2ef34a8, name="qt_scrollarea_viewport")
          MyTable(0x2efa8f8)
          QWidget(0x14094b0, name="centralWidget")
          MainWindow(0x61fde0, name="MainWindow")

          JonBJ Online
          JonBJ Online
          JonB
          wrote on last edited by JonB
          #23

          @Vlad02
          I have spent two hours so far this morning! I'm not going to lie, it's complex, and I don't have a solution and don't know whether I will get one/how long it will take!

          Basically the QTableView/QTableWidget is grabbing the Tab and dealing with it, without it getting to your QLineEdit.

          Some further information/clues from https://forum.qt.io/topic/97293/qtableview-navigation-with-tab.
          Also see bool QStyledItemDelegate::eventFilter(QObject *editor, QEvent *event), which tells you Tab is among the "special" keys handled by the QStyledItemDelegate, but not what you/I can do about it if we don't like it and want it to go to the line edit instead....

          V 1 Reply Last reply
          0
          • JonBJ JonB

            @Vlad02
            I have spent two hours so far this morning! I'm not going to lie, it's complex, and I don't have a solution and don't know whether I will get one/how long it will take!

            Basically the QTableView/QTableWidget is grabbing the Tab and dealing with it, without it getting to your QLineEdit.

            Some further information/clues from https://forum.qt.io/topic/97293/qtableview-navigation-with-tab.
            Also see bool QStyledItemDelegate::eventFilter(QObject *editor, QEvent *event), which tells you Tab is among the "special" keys handled by the QStyledItemDelegate, but not what you/I can do about it if we don't like it and want it to go to the line edit instead....

            V Offline
            V Offline
            Vlad02
            wrote on last edited by Vlad02
            #24

            @JonB
            Okay, thanks, these are useful links. I will try something else. This Tab is so ugly :)

            I will read about QTextEdit, maybe I can replace my LineEdit with it without any problems.

            JonBJ 2 Replies Last reply
            0
            • V Vlad02

              @JonB
              Okay, thanks, these are useful links. I will try something else. This Tab is so ugly :)

              I will read about QTextEdit, maybe I can replace my LineEdit with it without any problems.

              JonBJ Online
              JonBJ Online
              JonB
              wrote on last edited by JonB
              #25

              @Vlad02
              A QTextEdit is a different widget from a QLineEdit: it is multiline, and consumes Tabs & Returns itself. It is not "right" to replace your single line edit with a multi line just so you can deal with the Tab key the way you want.

              In have also come across https://stackoverflow.com/questions/12145522/why-pressing-of-tab-key-emits-only-qeventshortcutoverride-event, which shows how hairy all this stuff is!

              What is that you want do with the Tab key anyway? Normally it commits the data in the editor to the model and moves to the next cell. Explain (in no more than two words!) what it is you want to do/change about this behaviour?

              V 1 Reply Last reply
              0
              • V Vlad02

                @JonB
                Okay, thanks, these are useful links. I will try something else. This Tab is so ugly :)

                I will read about QTextEdit, maybe I can replace my LineEdit with it without any problems.

                JonBJ Online
                JonBJ Online
                JonB
                wrote on last edited by
                #26

                @Vlad02
                I can present a couple of code approaches which will stop the Tab key from doing its default, i.e. when editing in a QTableWidget it normally commits data from editor and moves to next cell, we can make it do "nothing". What I cannot do (if it's supposed to be possible) is then get the Tab key press to arrive at the QLineEdit's keyPressEvent().

                I'd really like to hear what exactly it is you do want to happen when Tab pressed now, per my previous request. Sooner you answer more likely I am to look at it :)

                [Looking earlier maybe all you want is it to do emit editingFinished();? Or the commitData() it does by default but not the move to another cell? Or what? I'm really not getting what you want to do, or why the default behaviour isn't perfectly good as it is?]

                V 1 Reply Last reply
                0
                • JonBJ JonB

                  @Vlad02
                  A QTextEdit is a different widget from a QLineEdit: it is multiline, and consumes Tabs & Returns itself. It is not "right" to replace your single line edit with a multi line just so you can deal with the Tab key the way you want.

                  In have also come across https://stackoverflow.com/questions/12145522/why-pressing-of-tab-key-emits-only-qeventshortcutoverride-event, which shows how hairy all this stuff is!

                  What is that you want do with the Tab key anyway? Normally it commits the data in the editor to the model and moves to the next cell. Explain (in no more than two words!) what it is you want to do/change about this behaviour?

                  V Offline
                  V Offline
                  Vlad02
                  wrote on last edited by
                  #27

                  @JonB said in Change focusOutEvent:

                  Explain (in no more than two words!) what it is you want to do/change about this behaviour?

                  • The cell selection behavior differs from the one I implemented;

                  • There are cases when I can only use cells of the first row and Tab should not move to the next rows

                  1 Reply Last reply
                  0
                  • JonBJ JonB

                    @Vlad02
                    I can present a couple of code approaches which will stop the Tab key from doing its default, i.e. when editing in a QTableWidget it normally commits data from editor and moves to next cell, we can make it do "nothing". What I cannot do (if it's supposed to be possible) is then get the Tab key press to arrive at the QLineEdit's keyPressEvent().

                    I'd really like to hear what exactly it is you do want to happen when Tab pressed now, per my previous request. Sooner you answer more likely I am to look at it :)

                    [Looking earlier maybe all you want is it to do emit editingFinished();? Or the commitData() it does by default but not the move to another cell? Or what? I'm really not getting what you want to do, or why the default behaviour isn't perfectly good as it is?]

                    V Offline
                    V Offline
                    Vlad02
                    wrote on last edited by
                    #28

                    @JonB said in Change focusOutEvent:

                    Or the commitData() it does by default but not the move to another cell?

                    Partially yes, I answered above. It should also finish editing the cell, save the data, and move on to the next one. But it is not always allowed to move to the next line

                    JonBJ 1 Reply Last reply
                    0
                    • V Vlad02

                      @JonB said in Change focusOutEvent:

                      Or the commitData() it does by default but not the move to another cell?

                      Partially yes, I answered above. It should also finish editing the cell, save the data, and move on to the next one. But it is not always allowed to move to the next line

                      JonBJ Online
                      JonBJ Online
                      JonB
                      wrote on last edited by JonB
                      #29

                      @Vlad02
                      OK. Sounds a lot like you only want to change where Tab moves you to next (commit data behaviour to be observed as-is).

                      I'm too tired now to type in complete code. I think you can figure from this.

                      What I played with is: the Qt code behind already does an installEventFilter() on your QStyledItemDelegate. So you can add your own eventFilter() override into it. You get Tabs there. If you return true that will filter it out from being passed on.

                      That was dealing with it close to the delegate. Another way is shown by @VRonin in https://forum.qt.io/topic/97293/qtableview-navigation-with-tab, which I asked you to look at earlier. He overrides the QTableView/QTableWidget's keyPressEvent(). If it's a Tab he accepts that event and creates a new key move event instead. Might be close/related to what you will want.

                      V 2 Replies Last reply
                      0
                      • JonBJ JonB

                        @Vlad02
                        OK. Sounds a lot like you only want to change where Tab moves you to next (commit data behaviour to be observed as-is).

                        I'm too tired now to type in complete code. I think you can figure from this.

                        What I played with is: the Qt code behind already does an installEventFilter() on your QStyledItemDelegate. So you can add your own eventFilter() override into it. You get Tabs there. If you return true that will filter it out from being passed on.

                        That was dealing with it close to the delegate. Another way is shown by @VRonin in https://forum.qt.io/topic/97293/qtableview-navigation-with-tab, which I asked you to look at earlier. He overrides the QTableView/QTableWidget's keyPressEvent(). If it's a Tab he accepts that event and creates a new key move event instead. Might be close/related to what you will want.

                        V Offline
                        V Offline
                        Vlad02
                        wrote on last edited by
                        #30

                        @JonB
                        Thank you for your help, rest, I will continue to think, referring to your tips and links

                        1 Reply Last reply
                        0
                        • JonBJ JonB

                          @Vlad02
                          OK. Sounds a lot like you only want to change where Tab moves you to next (commit data behaviour to be observed as-is).

                          I'm too tired now to type in complete code. I think you can figure from this.

                          What I played with is: the Qt code behind already does an installEventFilter() on your QStyledItemDelegate. So you can add your own eventFilter() override into it. You get Tabs there. If you return true that will filter it out from being passed on.

                          That was dealing with it close to the delegate. Another way is shown by @VRonin in https://forum.qt.io/topic/97293/qtableview-navigation-with-tab, which I asked you to look at earlier. He overrides the QTableView/QTableWidget's keyPressEvent(). If it's a Tab he accepts that event and creates a new key move event instead. Might be close/related to what you will want.

                          V Offline
                          V Offline
                          Vlad02
                          wrote on last edited by
                          #31

                          @JonB
                          You won't believe it! I looked at that article from stackoverflow. There, a person wrote that Tab only throws the ShortcutOverride event. I tried to make a check for this event, and then, according to the standard, cast to the QKeyEvent type. And it worked!!! I got the implementation I wanted when I pressed Tab. I want to thank you for spending so much time and effort to help me!

                          1 Reply Last reply
                          1
                          • V Vlad02 has marked this topic as solved on

                          • Login

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