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