Logic race with gSystem->ProcessEvents()?

ROOT
#1

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

#2

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

Thanks. Regards. Valeriy

#3

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