I would do so, yes. Even though I would not expect a threading problem with qFindChild as long as the object tree is not changing but one never knows.

@JonB

Thank you for your guidance.
I was able to solve this issue with your help.

For others facing this issue:

The connect() function that worked for me was:

QObject::connect(&futWatch, &QFutureWatcher<int>::finished, this, &myClass::onFinished);

And the onFinished() function was the same as suggested by Jon

Hi and welcome to devnet,

From the looks of it, you are likely accessing the QPushButton directly from your custom thread which is forbidden. GUI element manipulation shall happen in the main thread.

to continue the point @Christian-Ehrlicher mentioned above, blocking serial tasks usually exist on server daemon applications, but not on anything with user interaction or a GUI.

@sierdzio i think so, thank you so much !

@wumpus7 said in Qt::BlockingQueuedConnection With Null Receiver?:

Just to be clear, though, the sequence of events for emitting a blocking signal isn't:

Block Send signal (or don't in the case of no connection) Await return

Is it? Because the fact that the connection was gone wouldn't necessarily help if that were true, as the block would still occur, and the return still wouldn't.

I'm hoping that the sequence is, instead:

Send signal (or don't in case of no connection) Block and await return (if signal sent in step 1)

Try it and find out :) 'Tis the hacker way.

Do you mean that the UI should be responsive and the user could do something useful while the widgets are generated and shown one by one? You can probably use a zero timer signal and a slot for that. In this way everything happens in the same thread but the signals created by user interactions are handled between timer signals.

Thanks, I will check!

Well, I have no other ideas, sorry.

Hi, welcome to the forum.

Couple of things wrong here.

First, to be able to pass a method like this it needs to be static, otherwise there's no instance to run it on.
Second, to save you from unnecessary copies it should take the string as a const reference, not by value.
Third, similar to above, to save yourself from copies where not needed you should use a const reference in the foreach variable declaration.
Next, The return type of the function you pass should be the type of the element of the container, not the container itself i.e. QString in this case.
And last but not least - the call to map() is not blocking, so it will return immediately and the function will exit. You passed a local string list to it so it means the asynchronous calls will operate on freed memory and most likely crash. If you want to wait for the results you should rather use blockingMap() instead and if not then you need to store that string list somewhere for the whole duration of the map() execution.