block C++ and waiting for a qml signal to continue execution

Guigui64

Hello everyone, I'm currently working on a qml/c++ application (Qt 5.14.2) and please I need your help.
I want from the c++ side set visible a popup that is on the Qml side and block the C++ execution until the closing of the popup.

To achieve this, I use a QEventloop to block the execution and i connect the signal "closed" of the popup to the "quit" slot of the QEventLoop. But I have a problem, when I do that the GUI is blocked and i can do nothing. Would you know how I can solve this problem ?

You can see below a sample of my application:

the C++ function in which we want to wait the signal

void backend::press(){  
    setPopupVisible(true); //dispay popup on the qml side
    wait(); //wait for the close of the popup
    doSomeWork();//do something after....
}

The wait function

void backend::wait(){
    qDebug()<<"wait.....";
    QEventLoop loop;
    loop.connect(qmlPopup,SIGNAL(closed()),SLOT(quit()));
    loop.exec();

Thank you in advance for your help!

artwaw

@Guigui64 GUI freezes because you are blocking the main event loop. Don't.

Redesign your approach to take advantage of the signal / slot mechanism used in Qt.

Guigui64

Hi arwaw and thank you for your answer. The point is that it's completely the subject of my question, I want to find a way of not blocking the main event loop , I want to "wait" in the middle of the function and I have seen on some posts that using a QEventLoop might be a viable solution...
However I think that, as you recommend, I will turn to another solution, maybe split the code in 2 separate functions and avoid the "blocking" solution....

kshegunov

@Guigui64 said in block C++ and waiting for a qml signal to continue execution:

However I think that, as you recommend, I will turn to another solution, maybe split the code in 2 separate functions and avoid the "blocking" solution....

That's much better, and what you should do, yes.

As a side note, QEventLoop is used correctly, as far as your code goes and as far as I can tell, but you should avoid it in principle.