How to create Widget events before a.exec()?

Zark_zeugan

@SGaist
Okay so I have a C++ code that has its own class and functions, and the main function can run something like this:

int main(int argc, char** argv)
    
     cout << "Starting a processs"  << endl;
     call_func_to_perform_task()
     // This output from the function sends information that I need to log in on the debug Widget screen
     call_another_function()
     // Display output and log of this as well.

So the functions I call from main can internally generate some data needed to be displayed as logs or can give an output to the main functions that needs to be displayed.
But putting a.exec() at the end will mean that I have to wait a long time for all these functions to complete their tasks and then the Qt application being ready to create events that show logs. All I want is to create a GUI with a small text box displaying widget, that shows continuous logs of the processes.

JonB

@Zark_zeugan
Leaving aside the question of how you get the stuff to display from elsewhere (I don't know whether you have an issue there.)

The easier Qt way to do this would be to do your a.exec() "early". Then invoke your functions to do whatever, once, say you've shown the main window. In other words, let the Qt UI run, then when you do your stuff it's easy to display whatever.

JoeCFD

@Zark_zeugan anywhere inside the mainwidow to launch your app with qprocess or call your cpp run func.

Zark_zeugan

@JonB
But if i write a.exec() early on won't the program halt in that thread until exit() is called? Isn't that the reason why it is kept in the return statement of the main function?
Can you please explain with an example code?

Zark_zeugan

@JoeCFD
Okay I can look into that.
If you can please demonstrate an example, it would really help me understand better.

jsulm

@Zark_zeugan said in How to create Widget events before a.exec()?:

Can you please explain with an example code?

"Then invoke your functions to do whatever, once, say you've shown the main window" - I think what @JonB means is that you do the stuff for example in main window when it is shown. For example, you could use a one-shot timer started in main window constructor and in the slot connected to the timer do what you need.

Zark_zeugan

@jsulm
So, in my example I should create a signal to the PlainTextEdit slot and invoke that signal whenever I need to make the changes?
@jsulm
Also How can I call the widgets from a different functions other than the main?
e.g.
MainWIndow.cpp has a public member that can be called from main() by using

MainWindow w;
w.Display_Log();

But I want to do this in a different function
But if I create a new instance the widget collapses and the exits unexpectedly

jsulm

@Zark_zeugan said in How to create Widget events before a.exec()?:

But I want to do this in a different function
But if I create a new instance the widget collapses and the exits unexpectedly

Don't create a new instance use the existing one!
You can pass w as pointer or reference to that function.

Zark_zeugan

@jsulm
I am so sorry, but how can I do that? How do I pass it to a function?

jsulm

@Zark_zeugan said in How to create Widget events before a.exec()?:

How do I pass it to a function?

You should know how parameters are passed to functions/methods in C++, this is really basic:

void someFunction(MainWindow &w)
{
...
}
...
MainWindow w;
someFunction(w);

Zark_zeugan

@jsulm
Thank you and I will do better.

So, in my example I should create a signal to the PlainTextEdit slot and invoke that signal whenever I need to make the changes?

Was I correct regarding this?

jsulm

@Zark_zeugan said in How to create Widget events before a.exec()?:

Was I correct regarding this?

I'm not sure what you mean with this. Before you asked about calling something before a.exec() is executed. How is this new question related to this?

Zark_zeugan

@jsulm
Yes my question remains the same
You has suggested that

I think what @JonB means is that you do the stuff for example in main window when it is shown. For example, you could use a one-shot timer started in main window constructor and in the slot connected to the timer do what you need.

To which I drew the inference

So, in my case I should create a signal to the PlainTextEdit slot and invoke that signal whenever I need to make the changes?

I only wish to know if it is correct or am I missing something or maybe completely off the mark.

JonB

@Zark_zeugan said in How to create Widget events before a.exec()?:

@JonB
But if i write a.exec() early on won't the program halt in that thread until exit() is called? Isn't that the reason why it is kept in the return statement of the main function?

There is a lot to say about all of this, so here are a couple of notes/observations.

You need to get your head around Qt's event-driven paradigm. It is true that the final statement in main() of return a.exec() does not itself return until the UI is exited. However, lots of your code will be called during that a.exec(), via events/signals/slots..

To allow your "other" functions to be called while/after the UI has been shown you could create a QTimer before the a.exec(). They will then be called just after the UI has been shown initially.

Another factor to consider is how long your couple of functions will take to run, and whether you need output from them while they are running, rather than when they complete. It is easy to show call_func_to_perform_task()'s output before proceeding to call_another_function(). It is harder if you want to show their output while they are running. Which you may or may not demand. If you do need to show output the moment it is available: you either have to change their code to call QApplication::processEvents(), which is a little messy, or you would have to move them to a separate thread, which I hesitate to recommend for beginners as so many get this wrong as it's a bit tricky.

The neatest way to have them output as they go along is to use a signal with the text they want to show, and a slot which puts that into the desired widget.

Zark_zeugan

@JonB
Thank you I do get a clear idea of the situation now.
I agree I had not fully understood the event driven paradigm of Qt. Thank you for the explanation and the solution.