Logic race with gSystem->ProcessEvents()?

Hello,
Using v3.10/1 gdk root on win2k there’s a problem with gSystem->ProcessEvents(). If this call is made immediately after, e.g. TGProgressBar::SetPosition(), the application hangs the moment a repaint is needed. For an example of this, edit tutorials/guiTest, swap the order of the gSystem->Sleep() and gSystem->ProcessEvents() in TestProgress::DoGo(). Then launch the progress bar test, click go, then move the window - it freezes and never returns. Even without making this swap, occasionally I can make it freeze by moving it around.

Is it possible that this same race (if thats what it is) causes my TGPopMenu’s to occasionally become disconnected and non-working - please see TGPopupMenu flakeness

BTW: with non-gdk version of root, I never needed to call gSystem->ProcessEvents() - the TCanvas and the TControlBar would automagically repaint themselves as necessary. Now I need to put calls to gSystem->ProcessEvents() inside all of my busy loops to handle painting.

Has anybody eles noticed this problem? Is there a work-around for updating progress bar in busy loop without adding the Sleep()? I’ve tried the obvious - call gSystem->ProcessEvents() first, then call TGProgressBar::SetPosition() - it works usually, but it still, occasionaly hangs the app.

Ed

Hi Ed,
if this problem fixed or not with the current version of ROOT?

Thanks. Regards. Valeriy

Hello Valeriy,

The problem with gSystem->ProcessEvents() went away with version 3.10/2 (actually with a modified version of TGWin32ProxyBase.cxx you supplied on 12/19/03). This release also fixed disconnected popup menu issue.

I just downloaded and built the root v4.00/4 from tarred sources for win32gdk using vc++6.0. In a couple of hours “normal” testing, I saw no problems with gSystem->ProcessEvents() or pop-ups becoming disconnected. The shutter button behavior is fixed and the automatic dismissal of menu items when mouse leaves is very nice too. I have reverted back to 3.10/2 for now.

Ed