Well, actually, it was a really simple app - and it turned out the fix was very simple too - just run the following in a thread: void* ProcessEvents(void* arg) { while (true) { gSystem->ProcessEvents(); gSystem->Sleep(10); } return 0; } Is there any reason why there can't be a thread that just processes events like this by default? Or do the Xlib SMP problems prevent it? Matt On Thursday 13 June 2002 1:18 pm, you wrote: >Hi Matt, > > threads for such a big task might give problems. Use threads to run >small monitors for example and run the GUI as the main program. An >alternative is to use timers to regularly check the tasks you want to >minitor. > >Cheers, Fons. > >On Thu, 2002-06-13 at 12:54, Matt Palmer wrote: >> Hi, >> I would like to know if the following is possible: >> I want to write a GUI for some analysis code that is interpreted by CINT. >> This analysis code typically sits in a loop, so rarely exits. I would >> like to present status information, logging etc in a GUI. So, in order >> for the GUI to remain responsive to the user, I assume I would need to run >> the GUI in a separate thread. Is it enough to simply create a separate >> thread and then within that, create my main GUI object (a sub-class of >> TGMainFrame) ? I would then presumably make this object global so it can >> be accessed in the analysis code. >> >> I was worried by the statement in the TThread documentation saying that >> CINT will block all threads while it executes. Is this still true? If >> so, would moving the analysis code to compiled (something that I'm >> probably unable to do) code fix this? Is there any other way of doing >> this which I've totally missed? >> >> Thanks very much >> >> Matt
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:58 MET