That was a nasty one. Glad you found out and thanks for sharing !

I've found a solution, albeit with a small bit of help from ChatGPT as a last resort. I used an if/else statement (in the form of a ternary operator) for my main.qml and added an additional @Slot() decorator for the LED off function in my main,py.
.
.
↓ main.qml ↓

import QtQuick import QtQuick.Controls ApplicationWindow { width: 1920 height: 1080 visible: true // Bool property to hold the button state property bool buttonState: false // Function to toggle the LEDs function toggleLEDs() { buttonState ? controlPanel.buttonOff() : controlPanel.buttonOn(); buttonState = !buttonState; } Image { id: allLights source: "images/power_" + (buttonState ? "on" : "off") + ".png" anchors.centerIn: parent MouseArea { anchors.fill: parent onClicked: { toggleLEDs(); } } } }

.
.
↓ main,py ↓

import sys from pathlib import Path from led import grid, all_lights_on, all_lights_off from PySide6.QtCore import QObject, Slot from PySide6.QtGui import QGuiApplication from PySide6.QtQml import QQmlApplicationEngine class ControlPanel(QObject): def __init__(self): super().__init__() @Slot() def buttonOn(self): all_lights_on(grid) @Slot() def buttonOff(self): all_lights_off(grid) if __name__ == '__main__': app = QGuiApplication(sys.argv) engine = QQmlApplicationEngine() controlPanel = ControlPanel() engine.rootContext().setContextProperty("controlPanel", controlPanel) qml_file = Path(__file__).parent / 'main.qml' engine.load(qml_file) if not engine.rootObjects(): sys.exit(-1) sys.exit(app.exec())

I am not sure I follow what you are attempting to do, but mention of the private-dev packages perked my ears.

In a "Debian/Ubuntu"-esque environment, there are multiple *-private-dev packages, some of which are required for compiling additional libraries like QtMqtt.

apt search "private-dev"

for a long list for both Qt5 and Qt6. This may be the one you are looking for.

qtbase5-private-dev/jammy-updates,now 5.15.3+dfsg-2ubuntu0.2 amd64 [installed] Qt 5 base private development files

@Christian-Ehrlicher
I have used the -appstore-compliant option on the final .app made with Xcode. I used nm on the .app after using macdeployqt and it still showed the presence of the two APIs within it.

I think I will have to make my own custom Qt using the appstore-compliant feature.

Surely you mean I have to compile Qt with the "appstore-compliant" feature turned ON?

I know it is supposed to be turned ON by default for Qt downloaded through the maintenancetool. Maybe the Qt 6.4.2 that's available through the maintenance tool wasn't built with the appstore-compliant feature turned ON?

I managed to solve the problem.
The cause was my mistake in understanding how signals works in test environment.

During tests I have no EventLoop running, so the signal-slot mechanism of Qt can't work.
De facto, every time the assign method execute, I was emitting a signal using a Qt:QueueConnection, but there was no EventLoop running to process the signal queue.

Every time I call a setter method in test code, the next line have to be:

QVERIFY(signalSpy->wait());

which waits, no more than 5 seconds, running an internal EventLoop to process all emitted signals, and waiting for signals of the same type declared in QSignalSpy instance.

Since I had some methods with signal checks and some with only simple code checks (but both of them emit signals) I had a continuous jump between methods with and without QSignalSpy usage.

Since no EventLoop is running on tests, when I called the wait method on QSignalSpy instance, I was getting all the queued signals emitted on the previous test method, which also explain why I was getting constant numbers on signal counts.
I was not able to resolve just calling signalSpy->clear() in cleanup method because there was nothing to clear.

One solution could be to run the EventLoop between every tests method, just to be sure that the next test will handle only signals emitted in its code.
I resolved the problem implementing signals checks in every test method, which not only was my initial goal, but which ensure that every signal-emitting code is followed by a call to wait() method, which runs the EventLoop.
Every signal, now, is kept inside the test method and everything seems to works.

Thanks for support

@Amirhos
Unfortunately this is difficult, especially under Windows. If, for whatever reason, the third-party app is buffering its output at its own side then you cannot force it down the pipe to your parent, it depends how the code is written at their side....

@zeethree50 said in Libicu, needed by Qt5Core, compilation issues. Please help!! Worked fine in 18.04, but not 16.04.:

And it worked for me

Great, so please don't forget to mark your post as solved!

@kshegunov said in App crushes when Qt core calls WinAPI's "DispatchMessage" function:

This address is rather suspicious. Please tell me you don't have global QWidgets?

No, I have only a dll with function

extern "C" CORE_SHARED_API QMainWindow * svCreateMainWindow() { return new MainWindow; }

(CORE_SHARED_API is __declspec(dllexport))

@kshegunov said in App crushes when Qt core calls WinAPI's "DispatchMessage" function:

Btw, 0xc0000409 is stack overflow, so be on the lookout for endless recursion.

As I said, QWindowsGuiEventDispatcher::processEvents() is called twice, and I believe those calls are on the same stack level (crush happens in the second call).

@JonB Yeah I had an issue with QStorageInfo() so I am using GetFreeDiskSpaceEx() to calculate the available space.

You might have modified PATH in your terminal session only for example.

Or you may have modified PATH in the Run part of the Project panel.

Hi,

Thanks for sharing this ! Looks it might be worth including in Qt's platform notes for Android

@SGaist said:

should post this question to the development mailing list. You'll find the Qt's developers/maintainers (this forum is more user oriented)

A discussion on this topic started on that mailing list yesterday, for those who are interested: http://comments.gmane.org/gmane.comp.lib.qt.devel/23437

Hi and welcome to devnet,

In addition to @mrjj, can you show the exact error you have ?

It's been solved. "this" pointer was null, thus it was crazy debugging.

Easy: just edit the thread title and prepend [solved] :)

If you would like to discuss that issue further down, then I'd recommend asking it on the interest mailing list You'll find there Qt's developers/maintainers (this forum is mor e user oriented)