Problem hiding group frame

Dear Rooters

The enclosed macro “guiTestGroups1.C” shows my problem.

When I select tab “Group Test” then I see TGGroupFrame “Group 2”
below “Group 1” although it should be hidden! Only after selecting
“Group 2” from TGComboBox, is Group 2 displayed correctly.

The current macro is a slightly more complex version of macro
“guiTestGroups.C” where I had exactly the same problem, see:

In the case of the earlier macro, Ilka Antcheva thankfully could
provide a simple solution. Although I did not quite understand
the reason for this solution, it did solve my problem, see:

Sorrowly, for the current macro this simple solution no longer

I have tried different options, as you can see from the lines,
which I have commented out. Uncommenting these lines in any
combination will always result in even more strange behavior.

For this reason I have two questions:

  1. Does anybody know where the mistake may be hidden, and how
    this problem can be solved?

  2. Does there exist a general rule to follow, how to hide/show
    certain subframes? I must admit, that even after writing
    more than 30,000 lines of GUI code, I still could not figure
    out a general rule. Often, a trial and error approach solves
    my problems, but sometimes this does not help either.

Thank you in advance.

My system is ROOT 4.00/04 (28.Apr 04) on MacOS X 10.3.1.

Best regards
guiTestGroups1.C (14.8 KB)

Hi Christian,

Testing your example i noticed the following problems:

  • TGComboBox::Select(Int_t id) method does not emit any Selected(…) signal;
    the fix is in cvs now;

  • in method XFrameGroups::CreateTabTest(TGTab *tab) the lines:

[code] fTestBox->Select(1);

// fFGTst->HideFrame(fFGroup2);
// fFGTst->MapSubwindows();
// fFGTst->Layout();
} //CreateTabTest

can be replaced by:
// fTestBox->Select(1);



} //CreateTabTest[/code]

This is a work around that will run your macro more or less as you
would like. Selecting first combo box entry will show a broken layout.
I will investigate this problem later (I am very busy these days)
and anyone is welcome to explain the reason of this behavior.
In the GUI chapter on page 370 is included the info how to
hide/show sub-frames of a composite frame. In your first macro
you have put everything in one class and ti was easier to hide frames
in the constructor. Now your design is more complex and it is not
possible to follow this way.

Best regards, Ilka

Dear Ilka

Thank you very much for the fast work around.
I did not download yet the new cvs version, but I tested it by calling
directly instead of
and this solution seems to work.

My design is pretty complex, because I am using many shutter frames
and shutteritem frames. Altogether, currently I have already twelve
subframes where I use TGComboBox to hide other subframes, and until
now I did not have any problems hiding the subframes, but in most
cases the tabframes were subframes of groupframes.
I checked page 370 how to hide subframes: Interestingly, in my whole
application I am calling “frame->MapWindow()” only once at the end
of the main application constructor.
I hope that the broken layout can be fixed soon.

Best regards

Dear Rooters

After working some months on a different aspect of my program
I am now starting to work on my GUI application again.

Consider my surprise, when starting my program after compilation
with root 4.03/01 18 Dec 2004 on MacOS X my program suddenly looks
as shown in the attached Fig1.

  1. Problem:
    The problem seems to be that none of my subframes can be hidden
    at startup when using the new root version 4.03/01.

The enclosed macro “guiTestGroups1.C” shows once again my problem.
When I select tab “Group Test” then I see TGGroupFrame “Group 2”
below “Group 1” although it should be hidden! Only after selecting
“Group 2” from TGComboBox, is Group 2 displayed correctly.

Sorrowly, the proposed workaround by Ilka no longer works, in
contrast, now the problem has become worse, since until now I
have never experienced the problem shown in Fig1.

Does anybody know how this problem can be solved?

  1. Problem:
    My second surprise appeared when I started to test if my GUI
    program still works with the new root version. Adding trees
    from a root file from one TGLVContainer (fBContainer) to another
    TGLVContainer (fTContainer) suddenly changes the name of the
    trees to “frameXXX” as shown in Fig2.

In method DisplayTrees() I have the following code fragment
where the tree name is still correct:

   TGLVEntry *entry = 0;
   TIter next(fDataFile->GetListOfKeys());
   while ((key = (TKey*)next())) {
      if (strcmp(key->GetClassName(), "TTree") != 0) continue;
      TString treename  = key->GetName();  //CORRECT
      TString classname = key->GetClassName();

      entry = new TGLVEntry(fBContainer,treename,classname);

In method DoAddTrees() I have this code fragment, where
the name of the tree is suddenly changed to frameXXX:

   void *p = 0;
   TGLVEntry *entry = 0;
   TGLVEntry *selected = 0;
   switch (id) {
      case B_ADD_ALL: {
         selected = (TGLVEntry *)(fBContainer->GetNextSelected(&p));
         while (selected) {
            treename = selected->GetName();   //NOT CORRECT: frameXXX

            entry = new TGLVEntry(fTContainer,treename,"TTree");

            selected = (TGLVEntry *)(fBContainer->GetNextSelected(&p));

Could it be the GuiBuilder is somehow interfering with my program?

Thank you in advance.

Best regards
guiTestGroups1.C (15.1 KB)
Fig2.pdf (25.3 KB)
Fig1.pdf (20.9 KB)

Hi Christian,

I did not see this post up to now otherwise I would test the reported case. I am checking the forum several times per day and I really do not know how I could miss this post. Anyway, I will see what happens. The layout shown by the Fig.1 is very unpleasant!

Cheers, Ilka

Hi Cristian,

Please find as attached the macro guiTestGroups.C that does the job you want. Please note that it is based on code of the very first macro you have sent, but the application is redesigned another way. I was going to send you this example some time ago but the massive change of GUI classes required by the GUI builder stopped me. Anyway the macro is working with the last cvs and I hope it will help.

Best regards, Ilka
guiTestGroups.C (11.3 KB)

Dear Ilka

Thank you for your improved macro, sorrowly it can not be applied
to the more complex cases shown in macro “guiTestGroups1.C”.

Meanwhile, I have found a solution by adding a method HideSubFrames()
to each of the different subframes, as shown in the attached
macro “guiTestGroups2.C”.

Although more complex, I hope that this is a general solution which can
be applied to any complex GUI. At least, it did solve my problems.

Best regards
guiTestGroups2.C (15.9 KB)

Hi Christian,

The sent macro was not attempt to replace or redesign your application - it containes an exaple how to hide/show a group frame in a tab widget. For sure there are another ways to do it too. I am glad that your code works.

Best regards, Ilka