Can't call another class
paparucino at gmail.com
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 gmail.com <mailto:paparucino at gmail.com>> 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
> - 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...
More information about the PyQt