This and OS/App speed was my main reason why i'm using QTimer. To let other stuff get processed and loaded before.
Think about a design where each of the parts of "other stuff" has the ability to emit a signal when it is finished, so the next piece of "stuff" can start immediately after that. It doesn't have to be an actual Qt signal, just some flag or other indication that can be used to indicate a "finished" state. In your app, you can implement a state machine that starts the next task when each previous task says it is finished.
For example, create an enum of status flags:
enum TaskStateT
{
eInitialState = 0,
eTask1 = 1,
eTask2 = 2,
// ...
eTaskN = N,
eFinalState = N+1
} TaskState;
bool MainWindow::updateTaskState( TaskStateT state )
{
bool bFinished = false;
TaskStateT nextState = TaskStateT( state + 1 );
if ( nextState == eFinalState )
bFinished = true;
else
doTask( nextState );
if ( bFinished )
searchTable( 50 );
return bFinished;
}
void MainWindow::doTask( TaskStateT state )
{
switch( state )
{
case eTask1:
doTask1();
break;
case eTask2:
doTask2();
break;
// ...
}
// Current task is done, update and do the next
updateTaskState( state );
}
enum TaskStateT
{
eInitialState = 0,
eTask1 = 1,
eTask2 = 2,
// ...
eTaskN = N,
eFinalState = N+1
} TaskState;
bool MainWindow::updateTaskState( TaskStateT state )
{
bool bFinished = false;
TaskStateT nextState = TaskStateT( state + 1 );
if ( nextState == eFinalState )
bFinished = true;
else
doTask( nextState );
if ( bFinished )
searchTable( 50 );
return bFinished;
}
void MainWindow::doTask( TaskStateT state )
{
switch( state )
{
case eTask1:
doTask1();
break;
case eTask2:
doTask2();
break;
// ...
}
// Current task is done, update and do the next
updateTaskState( state );
}
To copy to clipboard, switch view to plain text mode
When the MainWindow constructor is exiting, the last thing it does is call updateTaskState( eInitialState ), which kicks off the set of things that must be done. When all are finished, the initial search can start immediately. You don't need to rely on magic timing numbers which might waste the user's time or start something off too early, depending on how much time the startup stuff takes.
If you want to keep the GUI "alive" while the initial processing is going on, you could a a call to QCoreApplication::processEvents() in the updateTaskState() method. This will run the event loop and ensure all pending events are handled. There are other ways to do it as well, such as making the state update and task execution into a signal / slot based implementation.
Bookmarks