About nested wait loop problem(using CActiveScheduler with in Qt app)

[wchunming]

I'll describe a problem I come across during tesing Qt feature. And post my explanation to this behavior.
I wanted to send my app to background. I was done in a button("mybutton") handler as follow:
TApaTask myRunningTask( CCoeEnv::Static()->WsSession() );
RWindowGroup& rg = CCoeEnv::Static()->RootWin();
myRunningTask.SetWgId( rg.Identifier() );
myRunningTask.SendToBackground();

CActiveScheduler::Start();

The app was send to background as I wished. When I switch to it again, everything seems ok except that the right-bottom "cancel" button cannot be used to quit the app.

When I debug the source code in emulator, I found that it is cause by nested wait loop problem. The app start a waiting loop in current thread, and in the handler or some event(such as button click), I start one more waiting loop. When I press the "cancel" button, the exit command is generated and the status of the app is set to quit, but the current thread is still waiting for the "mybutton" handling process to be done. So I can never quit the app after starting a second waiting loop without stop it.
Maybe A possible solution is: when I switch to the app manually, the main widget handle some event indicating the app is front again(stop the waiting loop start by me).
Hope this will be helpful to those who are testing CActiveScheduler.
This thread is also supposed to be an answer for my previous post: how to bring an app to back ground
-Revv

[jakoskin]

Thanks for the detailed description.
Creating a perfect event loop seems to be pretty difficult in mixed environment

[katroll]

It may be that I'm completely misunderstanding the problem, but as far as I can see, this is expected behavior. If you start an instance of the active scheduler, you also have to stop it. Qt will not do that for you (nor should it). If you call exit() from within a nested loop, Qt will terminate all the event loops that it owns, but it won't terminate CActiveScheduler loops, since it doesn't own those.

[wchunming]

I know what you meant. It is not the fault of Qt or S60 api, it is a problem of how to use S60 api properly with Qt. Qt did make a pretty good wrapper over S60 api. But the design of S60 api seems not so easily understood, sometimes they are even error-proned(Maybe it is only a problem of my own).