[Interest] pb with 530 official release and MAC/OS

[maitai at virtual-winds.org]

I'm doing processEvent() just to make sure the dialog is painted before 
an heavy treatment. Basically it shows "Please wait" while the process 
is running. I guess I am not the only one doing such things... If I 
don't call processEvents on some platforms the dialog is just half 
painted, probably there are other ways to ensure it's painted (like 
updateGeometry() ) but until now that was working.

I want to show(), do something, and then delete the messagebox. Not just 
show() and return, what would be the point? I don't want to exec() 
because I don't want the user to need to click on something, it's just a 
waiting message that should not block the execution.

It works fine on 521 whatever the platform, and it works fine on 530 
except for mac, this alone should sound like regression imo.

What I mean by lock:

My application becomes non-responsive. I can see that the main thread is 
continuing, until it returns (if I don't call processEvent() ). Then 
nothing else happens, ever. Probably because the waitBox is modal, and 
is never deleted since it should be deleted by a deleteLater() that 
never occurs because the event loop is locked ;)

Thanks for your patience

Philippe Lelong




Le 20-05-2014 21:13, Thiago Macieira a écrit :
> Em ter 20 maio 2014, às 19:04:39, maitai at virtual-winds.org escreveu:
>> Thanks for your reply
>> 
>> Why is removing the processEvent the right thing to do?
> 
> Because processEvents() means nested event loops. You shouldn't do 
> that. You
> should show() and then return;, so the non-nested event loops resumes
> executing.
> 
> If you do need to blocking-show, then don't use show(), just use 
> exec().
> 
> I'm interested in knowing whether there's a lock up if you use any of 
> the
> above solutions. And exactly what you mean by "lock".