PDA

View Full Version : Problem with return a.exec(). I need a solution here...



hakermania
3rd July 2011, 20:25
Hello developers!



My application is both console and GUI, depending on the arguments it takes.

So, the code is as follows:




#include.....

//..

class EarthTimer (bla bla, making a subclass of QTimer....

..
//here we connect the timer with the timers_slot() function
}

int main(int argc, char *argv[])
{
QApplication a(argc, argv);
EarthTimer earthtimer;
earthtimer.start(1800000); //30 min
return a.exec(); //we have started the timer but we have to call this otherwise the application will immediately close


}

void timers_slot(){
//doing some specific job
..//code
..
..
if(something_is_true){
MainWindow w;
w.show();
/*here I am trying to start the GUI, what it does is to go through the constructor
of the MainWindow class and then exits, without showing the GUI, I guess I have
to call return a.exec() again, but a is not declared here and cannot be global :(*/
}
}


Ι think the comments are pretty specific, but if someone didn't get it:
I call return a.exec() after starting the timer so as to avoid program's quit, and then if something is true in the timers_slot() I am trying to open the GUI. It goes through the constructor of the GUI but it does not show anything. I assume I have to call return a.exec() again there but it is declared in main() function and cannot be global.
May I create another QApplication and return it there?

ChrisW67
3rd July 2011, 23:44
It is a little odd that you want an application that does nothing visible at all for 30 minutes.

The way your code is above there is no way that the free function timers_slot() is actually a slot, cannot be the target of a connect(), and therefore never called after 30 minutes. However, assuming that timers_slot() is actually a member of EarthTimer and declared a slot then there doesn't seem anything grossly wrong in your code.

hakermania
4th July 2011, 08:06
It is a little odd that you want an application that does nothing visible at all for 30 minutes.

The way your code is above there is no way that the free function timers_slot() is actually a slot, cannot be the target of a connect(), and therefore never called after 30 minutes. However, assuming that timers_slot() is actually a member of EarthTimer and declared a slot then there doesn't seem anything grossly wrong in your code.

Thanks Chris for your answer. The above code is example code ofcourse. Yes, the timers_slot() is a 'public slot' of EarthTimer in the normal code and runs OK.
Additionally, the program displays info before starting the timer, so its work is to do a job every 30 min, nothing irrational :)

I know that my code hasn't something grossy, but I don't know how to call w.show() so as to show the GUI, because the GUI doesn't come up, it only goes through its constructor and exits!
See the last comments of my code in the 1st post for more info :)

ChrisW67
4th July 2011, 09:10
Actually, on a post-coffee viewing the problem is obvious. You allocate your main window on the stack (line 27) rather than the heap. The result is that the object is destroyed at the closing brace of the if statement. It doesn't show because it doesn't exist.

hakermania
4th July 2011, 13:13
Thanks, the problem is known :)

Can you suggest a solution?:confused:

FelixB
4th July 2011, 13:15
Can you suggest a solution?:confused:

Chris already gave you the solution, maybe he didn't state it clear enough:

create your main window on the heap instead on the stack.

stampede
4th July 2011, 13:28
... and that means with operator new ;)

hakermania
6th July 2011, 08:23
Thanks :) This was an easy solution :)
Can I find a link somewhere to understand better why was this done?

Asperamanca
6th July 2011, 11:10
Stack variables exist only as long as the function or block they were created in remains in scope


void foo()
{
int a;

{
int b;
} // b is destroyed
} // a is destroyed

When you read your code, the MainWindow w is destroyed once you leave your if-block.

Variables on the heap are destroyed explicitly using the "delete" statement - either you have to take care of that yourself, or use helper classes (e.g. the QObject tree can be used to automatically destroy children of QObjects)

That is, they exist until you tell them to go away.

Hope that helps

Robert