QElapsedTimer issue : code works on LINUX but not on MAC OS

PALYGAP

I have this delay function in my code :

void delay( int millisecondsToWait )
{
    QElapsedTimer timer;
    timer.start();
    while( timer.elapsed() < millisecondsToWait )
    {
        QCoreApplication::processEvents( QEventLoop::AllEvents, 100 );
    }
}

It is called in an initialization() function of the Main Window :

void MidyAX::initialization()
{
/////
Some custom processing with MIDI connexion init and sending and receiving MIDI messages
/////

    connect(this, SIGNAL(learnedMapping( unsigned char, int )), dlgBCF2000(), SLOT(updateWithLearnedMapping( unsigned char, int )) );
    connect(this, SIGNAL(learnedMapping( unsigned char, int )), dlgRotEncLayOut2(), SLOT(updateWithLearnedMapping( unsigned char, int )) );

    delay(100);
    m_initPhase = false;
}

and this initialization() is called in the main window constructor.

On LINUX it works fine but on MAC it does not return. Weird !

Did someone experienced that kind of behavior ? or have an idea of what's going on here ?

SGaist

Hi,

Do you mean delay never returns ?

By the way, why do you need that delay ?

PALYGAP

Hi,

Yes the delay never returns or the condition to stop the loop is never TRUE : "while( timer.elapsed() < millisecondsToWait ) "

The application receives MIDI messages (it has ask for) from a MIDI deveice. If the timer is not put in some of the MIDI messages are received/processes after the end of the initialization() function. On Linux the same code works fine. Since receiving these MIDI messages triggers the display of a QDialog, the timer is there to avoid calling that dialog during the initialization phase.

Thanks for taking interest in my problem. A friend with experience in Qt says it is likely that since the timing functions are closely associated the OS it is not too surprising that there is a difference in behavior. I look on the WEB for people reporting similar problems but did not find anything.

SGaist

While it's strange, I wouldn't make the success of the initialization based on such a timer.

I'd rather have a signal telling the initialization is done once you received the MIDI message(s) you need. Then you can trigger the next step of your application.

PALYGAP

Thanks for the suggestion. I have thought of counting the received MIDI messages to make sure all the expected messages have been received and then trigger an even. I might go that way if i can't find a solution that avoids doing that.

SGaist

Aren't you waiting on a set of known messages ?

PALYGAP

Yes, but I wanted to avoid putting a treatment specific to the initialization process in a function that is receiving the MIDI messages during normal operation of the program.

SGaist

You can write an initializer class that does only this and once done the messages are routed to your usual class.

PALYGAP

Not so sure what you mean. Had a look on the WEB but did not find much.
The things is the MIDI reception is triggered by the MIDI lib (RTMIDI) when is callback the function it is setup to call back (MIDIcallback) and this function is not part of a class. So I would immagine that having an initializer class implies that having this MIDIcallback function inside that class. Just guessing here.

SGaist

You can pass anything you want in the userData parameter so you could use that to pass a custom Midi message handler.

In that handler you'll check the message that you receive and once you got all the initialization messages you can emit something like a "initialized" signal and then process the rest of the message normally.

PALYGAP

Yes userData could be used, but it's allready used to pass the pointer to the QtMainWindow since the function send "reception" messages to a few QDialogs.

SGaist

You can pass a custom struct that contains all the pointers to objects you need.

PALYGAP

True. I though about it at one point but didn't want to bother with it at the time ... I might just have to do that.

Thanks a lot for all your help.

But in the end, it seems the initial problem ( delay() not returning ) might be specific to Qt5.5.1 on mac. I will try it out with Qt5.6. Who knows it might work. ;)