Language Bindings

In the compilation output the error is displayed as follow :

16:01:10: Start: "C:\Qt\Tools\mingw810_32\bin\mingw32-make.exe" -j8 C:/Qt/Tools/mingw810_32/bin/mingw32-make -f Makefile.Debug mingw32-make[1]: Directory Entry 'C:/Users/operateur/Documents/CB/WD_V5-masterv2' mingw32-make[1]: Nothing to do for 'first'. mingw32-make[1]: Leaving the directory 'C:/Users/operateur/Documents/CB/WD_V5-masterv2'

I am new in QT using C++ 98

It's almost 2023. It's time to move on :)

As for the code - it's kinda all over the place.

You're just iterating over some widgets. Why do you even need a signal mapper here? Especially since you map those widget to themselves? That doesn't make sense.

find_child will return nullptr if it couldn't find anything. You're not checking that so you're probably getting nullptr and then trying to call btn->setStyleSheet on it. That will crash.

Those buttons don't seem to be children of the signal mapper. At least there's no code here that would make them that. Your signal mapper doesn't have any children here, so find_child won't find anything and will return nullptr. You should call find_child on the actual parent of those buttons.

In any case, find_child operates on object names, not variable names. Are these widgets actually named with setObjectName()? If not then find_child will not find them and return nullptr.

@withwind You need to have something like

target_link_libraries(demoPing libPing...

@All Compared to an auto- connection writing a manual connection requires much more time and is more difficult to debug (exp. finding a particular connection in the source – The Goto slot… helps finding the location in the source). In this relatively large project it would take more than a month to repair all connections. I personally like these kinds of automatisms.

Therefore I did some further analysis. First of all the auto-connections are only non reliable in terms of understanding what is going on. But the reported issue here is 100% reproducible.
In fact the moc is not guilty at all and compiles correctly as the dispatcher code being produced by the moc has all the required calls:

void MainWindow::qt_static_metacall(QObject *_o, QMetaObject::Call _c, int _id, void **_a) { if (_c == QMetaObject::InvokeMetaMethod) { MainWindow *_t = static_cast<MainWindow *>(_o); switch (_id) { ... case 35: _t->on_firstToolButton_clicked(); break; case 36: _t->on_prevToolButton_clicked(); break; case 37: _t->on_nextToolButton_clicked(); break; case 38: _t->on_lastToolButton_clicked(); break; case 39: _t→on_navigationLabel_linkH …

This dispatcher method is called from another method

int MainWindow::qt_metacall(QMetaObject::Call _c, int _id, void **_a) { … }

and that one is called from a code section only displayed in assembly code.
Assuming, that the _id for the dispatcher might be wrong I added a breakpoint to check, but while for all other buttons this call is executed, pressing the prev and next button this metacall method not even reached.

As it tends to be reproducible I analysed the source files and with the help of GIT I figured out, that the only difference is in the MainWindow.ui:

... 1968 1968 <property name="locale"> 1969 1969 <locale language="English" country="UnitedStates"/> 1970 1970 </property> 1971 <zorder>toolWidget</zorder> 1972 1971 </widget> 1973 1972 <widget class="GraphicsWidget" name="recentPage"> 1974 1973 <property name="locale"> ... )* The first two columns are showing the line numbers as shown with GIT before/after

Somehow the designer added the <zorder> key somewhen before yesterday, and re-assigning the slots was removing this line again.

I have to add that the toolWidget is a container with a QGridLayout for all my buttons (about a dozen more) used to fade in and out the buttons simultaneously.

For me it looks like that auto-connections can safely be used, unless a <zorder> key is present in the .ui file.
So the remaining questions are:

What did the designer cause to add the <zorder> key? Why only 2 QToolbutton were affected, but all others are working Ok?

@dobiz22
Just that it is better "style" to access via getters & setters. Hides some of the internals, allows a bit of extra code to be put into the getter/setter if required (e.g. validation), you can place a debugger breakpoint on them, that sort of thing.

@busrazone Again: what build system do you use? QMake? CMake? Plain Makefile?

This worked, thank you!

@JonB Yeah I used to do that, and it worked fine on PyQt5, but unfortunately it doesn't work at all on pyside6 (ditto pyside2 based on past discussion).

Hi,

What color do you want to change ?
The text color ?
The background ?
Both ?

@JonB
That sounds cool. Will follow your suggestion.

@SGaist Ok
I will try and return the result.
Thanks for your support

@SGaist thank you. What we have at the moment is a pretty vanilla console and I had been thinking about how to extend that with some limited GUI facilities. But the ipython route isn't something I had considered and I wasn't aware of the Qt console. It would be a change of direction but certainly something to consider and investigate. Thanks again.

The problem was solved.
Replace QVariant -> "QVariant"
The correct definition of the signal in python code is:

toUI = Signal(str, "QVariant")

Refer: https://github.com/mottosso/Qt5.py/issues/5