Launching a TGMainFrame from a script

ROOT
1

I am using win32gdk version 3.10/2. The following script is used to launch my application:void maingui(const char *fname="") { gROOT->Reset(); gSystem->Load("analysis.dll"); CAnalysis *pm = new CAnalysis(gClient->GetRoot(),800,700); if (fname && *fname) pm->ProcessInputFile(fname); }where CAnalysis is a TGMainFrame derived class. When root + the script are launched from the command line asroot -l maingui.cppeverything works fine - the gui gets drawn and the user can interact with it just fine.
When root + the script are launched asroot -l maingui.cpp(\"input.proc\") then the ProcessInputFile() method is called - this may take minutes to complete (it is liberally peppered with gSystem->ProcessEvents() calls). The problem is that the gui does not completely paint itself until ProcessInputFile() completes - no menubar, toolbar or sliders are drawn, One shutter and its buttons are drawn, but no text is displayed and the status-bar is not laid out properly. Is there way to force the gui to completely paint itself before (or even while)ProcessInputFile completes? Thanks

Ed

Note: CAnalysis’s ctor ends with: MapSubwindows(); Resize(GetDefaultSize()); MapWindow();

2

Hi Ed,
could you put somewhere in pm->ProcessInputFile
periodical call of gSystem->ProcessEvents()
You can also try to start a timer which will force refreshing
like

 TTimer *rfrsh = new TTimer(200); // 200 ms
 rfrsh->Connect("Timeout()", "TSystem", gSystem, "ProcessEvents()");

If it helps?

Regards. Valeriy

3

Hi Valeri,
pm->ProcessInputFile() already does make periodic calls to gSystem->ProcessEvents() - approximately every 100 msec.
Ed

4

Hi Ed,
I was quick and missed this point.
Can you check this problem against CVS head ROOT?

Regards. Valeriy

5

Hi Valeriy,
The current cvs version does not have the problem. Thank you!
I still need to verify this version before I can release to my users - there were occasional gui crashes I saw with 4.00/03 that I never saw in 3.10/02 (13-Apr-2004 email: TCanvas::HandleInput() crash in kMouseMotion case), still some problems including Form() behavior and the new TH2::Draw(“colz”) behavior that I need to work around before I can start using it.
Ed

6

Hi Ed,
could you check “TCanvas::HandleInput() crash” against 4.00.06?
Concerning Form problem, check two citations from Fons mails

Thanks. Regards. Valeriy