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. Signals for positions of widgets changed in QTableWidget
Forum Updated to NodeBB v4.3 + New Features

Signals for positions of widgets changed in QTableWidget

Scheduled Pinned Locked Moved Solved General and Desktop
qtablewidgetchange in widge
8 Posts 3 Posters 4.0k Views 3 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.
  • K Offline
    K Offline
    koahnig
    wrote on last edited by koahnig
    #1

    I have a QTableWidget populated with QLineEdit and some custom buttons. The is no QTableWidgetItem in there, only widgets. I face the problem that access and changes cannot be monitored through (at least not the ones I have tried).

    Certainly I can track that the QLineEdit have been accessed and changed, but I need to know where there widget is located for some action.

    Is there really no way to get the indeces for those widgets?

    Those three I have tried so far.

    connect ( ui->twCommands, &QTableWidget::cellPressed, this, &SerialDialog::sltPressed );
    connect ( ui->twCommands, &QTableWidget::cellActivated, this, &SerialDialog::sltActivated );
    connect ( ui->twCommands, &QTableWidget::cellChanged, this, &SerialDialog::sltChanged );
    

    Vote the answer(s) that helped you to solve your issue(s)

    kshegunovK 1 Reply Last reply
    0
    • K koahnig

      I have a QTableWidget populated with QLineEdit and some custom buttons. The is no QTableWidgetItem in there, only widgets. I face the problem that access and changes cannot be monitored through (at least not the ones I have tried).

      Certainly I can track that the QLineEdit have been accessed and changed, but I need to know where there widget is located for some action.

      Is there really no way to get the indeces for those widgets?

      Those three I have tried so far.

      connect ( ui->twCommands, &QTableWidget::cellPressed, this, &SerialDialog::sltPressed );
      connect ( ui->twCommands, &QTableWidget::cellActivated, this, &SerialDialog::sltActivated );
      connect ( ui->twCommands, &QTableWidget::cellChanged, this, &SerialDialog::sltChanged );
      
      kshegunovK Offline
      kshegunovK Offline
      kshegunov
      Moderators
      wrote on last edited by kshegunov
      #2

      I don't know if understand the question correctly, but I think QTableWidget::item or at least QTableWidget::itemAt should work? Also what do you mean there's no QTableWidgetItem? As far as I know the class for any widget you put in there, Qt will automatically wrap it in an item instance.

      Read and abide by the Qt Code of Conduct

      K 1 Reply Last reply
      0
      • kshegunovK kshegunov

        I don't know if understand the question correctly, but I think QTableWidget::item or at least QTableWidget::itemAt should work? Also what do you mean there's no QTableWidgetItem? As far as I know the class for any widget you put in there, Qt will automatically wrap it in an item instance.

        K Offline
        K Offline
        koahnig
        wrote on last edited by
        #3

        @kshegunov

        Sorry, I should have mentioned probably signals and slots as I am using in the example.

        I am using cellWidget for getting a pointer to the widgets stored. You need a cast for access the proper type. That is working. With item and iteAt you are getting only acces to the QTableWidgets if you chose to use those. They were not of help.

        Since the "cell" stuff seem to be for widgets and "item" stuff for QTableWidget I have expected to get some responses through signals starting with cell, but no success yet.

        Vote the answer(s) that helped you to solve your issue(s)

        kshegunovK 1 Reply Last reply
        0
        • K koahnig

          @kshegunov

          Sorry, I should have mentioned probably signals and slots as I am using in the example.

          I am using cellWidget for getting a pointer to the widgets stored. You need a cast for access the proper type. That is working. With item and iteAt you are getting only acces to the QTableWidgets if you chose to use those. They were not of help.

          Since the "cell" stuff seem to be for widgets and "item" stuff for QTableWidget I have expected to get some responses through signals starting with cell, but no success yet.

          kshegunovK Offline
          kshegunovK Offline
          kshegunov
          Moderators
          wrote on last edited by kshegunov
          #4

          I reread your original question and I think I get what you mean. The only way I can think of off the top of my head is to hash the widget positions by yourself, e.g in QHash<QObject *, QPoint>. And connect the destroyed() signal from the widget to a method to remove the item from the hash (obviously the hash would be populated alongside your table widget). I'm not aware of any finer method, sorry.

          Read and abide by the Qt Code of Conduct

          K 1 Reply Last reply
          1
          • kshegunovK kshegunov

            I reread your original question and I think I get what you mean. The only way I can think of off the top of my head is to hash the widget positions by yourself, e.g in QHash<QObject *, QPoint>. And connect the destroyed() signal from the widget to a method to remove the item from the hash (obviously the hash would be populated alongside your table widget). I'm not aware of any finer method, sorry.

            K Offline
            K Offline
            koahnig
            wrote on last edited by
            #5

            @kshegunov

            I found a solution with QSignalMapper. You can give each widget's address into the signal mapper. The mapper would provide the widget's address to a slot of your app. This address can be searched and found in the table and used. General loops over rows and columns have to be searched.

            It does work in my case. However, really happy I am not. I am wondering if I am not missing something.

            Vote the answer(s) that helped you to solve your issue(s)

            kshegunovK 1 Reply Last reply
            0
            • SGaistS Offline
              SGaistS Offline
              SGaist
              Lifetime Qt Champion
              wrote on last edited by
              #6

              Hi,

              You can mix the QHash and the QSignalMapper solution. That will take a bit more RAM but will be quicker to lookup than a search in the table.

              AFAIK, you didn't miss anything, the cell widgets "cover" the cell. They are not a replacement for the QStyledItemDelegate which would let you use the usual signals.

              Interested in AI ? www.idiap.ch
              Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

              1 Reply Last reply
              3
              • K koahnig

                @kshegunov

                I found a solution with QSignalMapper. You can give each widget's address into the signal mapper. The mapper would provide the widget's address to a slot of your app. This address can be searched and found in the table and used. General loops over rows and columns have to be searched.

                It does work in my case. However, really happy I am not. I am wondering if I am not missing something.

                kshegunovK Offline
                kshegunovK Offline
                kshegunov
                Moderators
                wrote on last edited by
                #7

                @koahnig said in Signals for positions of widgets changed in QTableWidget:

                I found a solution with QSignalMapper.

                Yes that should work too.

                However, really happy I am not. I am wondering if I am not missing something.

                Not to my knowledge.

                Read and abide by the Qt Code of Conduct

                1 Reply Last reply
                1
                • K Offline
                  K Offline
                  koahnig
                  wrote on last edited by
                  #8

                  Thanks guys for your suggestions.
                  Probably I am following the QHash implementation as next step. The proximity to maps make it easy.

                  Vote the answer(s) that helped you to solve your issue(s)

                  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