Can't call another class

[Maurizio Berti]

Il giorno mar 7 set 2021 alle ore 13:52 paparucino <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).

Why should I use the ui file?
>
> You wrote "That's one of the many reasons for which files generated by
> pyuic should ** NEVER ** be modified, unless you * really * know what
> you're doing, which assumes you * do * know what their classes are and how
> they work. " Let's start with the fact that I struggle to work with the
> classes and therefore your reasoning is impeccable, but to verify if what I
> did with the designer was what I wanted I had to modify the original.
> Everything works as I wish but the problem remains of linking it to the
> rest of the project, just as I wrote above.
>
An UI created in designer (both the UI file or the python generated code)
is the *base* state of the interface, almost like a template.
Any aspect that has to be changed at runtime should be then implemented in
the logic of the code, based on that "template".
If you had to modify the original to verify that the UI is what you wanted,
it means that the UI was not created correctly.

Conceptually, the UI is itself a "class", then you subclass it to add
features or modify its behavior. If you have to modify the class for that,
it means that the original class was not right in the first place, and
since that UI "class" was created in designer, you should use that to
change it. And if your UI has to change programmatically, then you should
create the UI in order to allow that.

Altering the pyuic file is not a good idea for many reasons:
- 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;

"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.

You said that you struggle to work with classes, and I can relate with
that: it took me a lot to understand the principle years ago, as my limited
programming experience at the time was mostly procedural.
But Qt and python are object oriented, and knowing how their classes work
and how to use them is mandatory.
As soon as you learn how to deal with them (especially under PyQt) you'll
understand that not only it *makes sense*, but it actually (usually) can
make things simpler.

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:
> https://stackoverflow.com/questions/65493443/qtablewidget-column-span-doesnt-resize-correctly
> )
>
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):
        model = self.model()
        header = self.verticalHeader()
        opt = self.viewOptions()
        spanned = False
        hint = 0
        for row in range(model.rowCount()):
            if header.isSectionHidden(row):
                continue
            if self.columnSpan(row, column) > 1:
                spanned = True
            else:
                index = model.index(row, column)
                opt.index = index
                delegate = self.itemDelegate(index)
                hint = max(hint, delegate.sizeHint(opt, index).width())
        if spanned and hint:
            return hint
        return super().sizeHintForColumn(column)

Cheers,
Maurizio
-- 
È difficile avere una convinzione precisa quando si parla delle ragioni del
cuore. - "Sostiene Pereira", Antonio Tabucchi
http://www.jidesk.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20210907/62f2d830/attachment-0001.htm>