QTableWidget Not expanding to size of QDockWidget

[d_stranz]

This is a really confused design. "PhysEqSolver" is, in effect, the model, since it appears to be the source of data that is displayed in the table. It is completely unnecessary to derive this from QTableView and in fact that might be part of the source of your GUI problems.

The PhysEqSolverTable table widget that is created as part of the PhysEqSolver class should be the instance that is inserted into the dock widget. It should be created by the code that creates the dock widget (a QMainWindow-based class, likely). If for convenience, you want to store a copy of that pointer in the PhysEqSolver class, that's fine, but the Model / View architecture works the other way around - the model pointer is stored on the view, not vice-versa.

Most of the code you have in the PhysEqSolver class for interacting with the table cells should be moved to the PhysEqSolverTable class. This is probably another source of GUI problems since it is likely you are handling signals for one GUI object (the table VIEW) using a different GUI object (the table WIDGET).

[Caolan O'Domhnaill]

This is a really confused design. "PhysEqSolver" is, in effect, the model, since it appears to be the source of data that is displayed in the table. It is completely unnecessary to derive this from QTableView and in fact that might be part of the source of your GUI problems.

The PhysEqSolverTable table widget that is created as part of the PhysEqSolver class should be the instance that is inserted into the dock widget. It should be created by the code that creates the dock widget (a QMainWindow-based class, likely). If for convenience, you want to store a copy of that pointer in the PhysEqSolver class, that's fine, but the Model / View architecture works the other way around - the model pointer is stored on the view, not vice-versa.

Most of the code you have in the PhysEqSolver class for interacting with the table cells should be moved to the PhysEqSolverTable class. This is probably another source of GUI problems since it is likely you are handling signals for one GUI object (the table VIEW) using a different GUI object (the table WIDGET).

Ahhhhhhh. Okay...

This was the way that the sample I used was designed. Since I am learning and new to QT I have just run with it.

I'll redesign some and see if that helps the UI issue...

[Caolan O'Domhnaill]

Hey there Anda I finally had a chance to review this and yes after some investigation I realised that perhaps because I was developing the UI myself rather than use the QT Creator I wasn't doing it correctly. So I branched my code and rebuilt the UI using the QT Creator app, thereby doing it the right way, and many issues I was having are no longer there.

In addition i came to realise that my understanding of the View/Model architecture was sorely lacking so I spent some time with that as well. Although much of my application remains the same, the UI base has been refactored greatly and the problems I was encountering in this thread are now gone. That was because I was confused by the documentation between QTableView and QTableWidget when it said that QTableWidget is a helper class...

Anyway, this problem has now been averted.