Can't call another class

paparucino paparucino at
Wed Sep 8 15:47:25 BST 2021

On 9/7/21 11:21 PM, Maurizio Berti wrote:
> Il giorno mar 7 set 2021 alle ore 13:52 paparucino 
> <paparucino at <mailto:paparucino at>> ha scritto:
>     One of the first attempts I made was just to insert QMainWindow
>     but since there is already a QMainWindow (the general of the
>     project) every time I selected a month to view the script it
>     triggered a script that had nothing to do with what was requested.
>     QtObject is just the last of my attempts and it stayed there when
>     I wrote the email.
> If I understand what you wrote, that happens because you called 
> setupUi on self, as explained in my previous message.
> If you want to create a *new* window with the given parameters, you 
> should use a new QMainWindow instance (or use a class as in my examples)

Which is what I'm doing besides going crazy :)

> - whenever you have to change even the slightest aspect of the UI, you 
> have to integrate those changes by merging your existing code, which 
> is a painful process that almost always leads to bugs and lots of 
> headaches;
> - it's *not* intended for modification, as it's just a "translation" 
> of the UI xml into python code, and should always behave exactly like 
> using the loadUi function with the same source UI file;
> - modification usually leads to unexpected behavior if you don't 
> really know what you're doing and how those files work;
I never edit the ui file. I keep it as a base and eventually I create 
many .py files depending on how the debug goes. I know that it is 
confusing and that I fill the dir with files but sometimes I start from 
an idea and as everything evolves I can change my mind and therefore I 
have a base plus a certain series of more or less functional back ups
> "Linking to the rest of the project" then means that you start from 
> that "template" and integrate it with the actual, final program logic.
> Let's suppose your program has to show an undefined number of tables 
> based on the contents of a database. This probably means that you 
> should create a UI that has *no* table at all, and only has a 
> placeholder or container that will then be used to put those tables 
> into. In your program you will then actually create those tables 
> according to your needs.
The example is perfect, but if I don't have an entry point for my tables 
in the ui-> py file, I don't know where to start. I created a ui file 
with scrollArea containing a number of tables, transformed it into py, I 
"analyzed the code, I deleted all the tables by inserting mine, with the 
necessary changes. Result: I get what I expect. Then the problems begin. .
>     A stackoverflow user advised me to use this system because I had
>     problems in the first two rows of the tables that would then end
>     up in the infamous scrollArea (see:
>     <>)
> I remember that question (I pointed you out to the bug report, which 
> seems resolved but only since Qt6.1).
> While the proposed answer works, a more appropriate and consistent 
> solution could be to override sizeHintForColumn. The following is a 
> very basic implementation, as it doesn't consider more extended 
> aspects and isn't suitable for very large models.
> class TableWidget(QTableWidget):
>     def sizeHintForColumn(self, column):
>         #

Thank you, later will give it a try. Actually I need to fill the 
scrollArea with my tables.

Now I try to prepare a reproducible code because I can't get out of it



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the PyQt mailing list