One function in connect() and QTimer::singleShot()

[ZajtiM]

Thank you for all the info.

App will be running on fairly old PC and there is some other stuff that needs to be processed and loaded (from DB). I was forced to install x64 OS, to install QT on it and is not as fast as i would like (PC and python version App). I did search for lighter versions of Linux, because i don't need anything extra on that PC.

Search table is not first thing user will see, when MainWindow is visible (i'm using stacked widget). This and OS/App speed was my main reason why i'm using QTimer. To let other stuff get processed and loaded before.

QTimer with 8500 might be premature at this point, so i might change it later. I started working on C++ version 5 days ago, so i have plenty of time to change QTimer etc.

I will be using this for now. But as i said, i might change it later.

// LOAD TABLES
    QTimer::singleShot( 8500, this, SLOT( doInitialSearch() ) );
 
 // etc..
}
 
void MainWindow::doInitialSearch()
{
    searchTable( 50 );
}

// LOAD TABLES
    QTimer::singleShot( 8500, this, SLOT( doInitialSearch() ) );
 
 // etc..
}
 
void MainWindow::doInitialSearch()
{
    searchTable( 50 );
}

To copy to clipboard, switch view to plain text mode 

[d_stranz]

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.