From: jonas@beor.informatik.rwth-aachen.de (Josef Nelissen)
Subject: Non default PanedWindow resources seem to affect TabGroubs
Summary: TabGroup creation seems to depend on dimensions of PanedWindows
Keywords: PanedWindow, TabGroups, XmProcessTraversal
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
Date:  9 Sep 92 07:53:59 GMT

Hi guys,
I'm very confused by the behaviour of the PanedWindow-Widget according
to its creation of TabGroups.
In the course of fine tuning the appearance of my current
X/Motif-project, the following problem occured: I present to the user
the following input window

    ---------------------------------------------------------------
    |	                                                          |
    |               --------                        --------	  |
    |		    |      |                        |      |      |
    |    <text>     |	   |             <text>	    |	   |      |
    |		    |	   |			    |	   |	  |
    |               --------                        --------	  |
    |								  |
    |               --------                        --------	  |
    |		    |      |                        |      |      |
    |    <text>     |	   |             <text>	    |	   |      |
    |		    |	   |			    |	   |	  |
    |               --------                        --------	  |
    |								  |
    |-------------------------------------------------------[]----|
    |	                                                          |
    |      ------         -------        --------    ------       |
    |      | ok |         |clear|	 |cancel|    |help|	  |
    |      ------         -------        --------    ------       |
    |                                                             |
    ---------------------------------------------------------------


consisting of a PanedWindow-Widget, an RowColumn-Widget and a
Form-Widget with with four pairs of Label-Gadgets/Text-Widgets and four
PushButton-Gadgets respectively.
Being a great believer of the bible (the Motif Programming Manual by
Dan Heller) I had added the XmProcessTraversal-Function with an
argument of XmTRAVERSE_NEXT_TAB_GROUP to the XmNactivateCallback of
the TextWidgets, as explained at page 510/511. Up to now, this
happened to work fine; after hitting return at the last TextWidget,
the Focus changed to the ok-Button and another return closed the
Window.

As I tried to indicate through the "[]" in my sketch above, the
SashWidget-Child of the Pane was displayed - in fact I hadn't changed
any resources of the pane so that the defaults applied.
Well, trying to hide the Sash by setting XmNsashWidth/Height to 1, as
suggested at page 208 of the bible, resulted in some confusion with
respect to the TabGroups - hitting return at the last Text-Widget
now puts the Focus at the Sash, as could be verified by another Tab,
which put it to the ok-button. Getting curious I tried out how the
TabGroupSequence was without any special settings and found out, that
the Sash was traversed *after* the ok-button in this case.

Well, but not enough of confusion - by try and error I found out, that
everything worked as before (double return did it) if I only set
XmNsashWidth to 1 and left XmNsashHeight at the default.
As these settings result in an invisible Sash as well (o.k. not
exactly, but the remaining two disturbed pixels didn't bother me),
I was nearly satisfied and only added a XmNspacing of 15 to the Pane
for a last improvement of layout - only to run into the same trouble
as before!
In fact, either setting of XmNsashHeight to a nondefault value or
increasing XmNspacing to a value higher than the default (8) inserted
the Sash between the text-Widget and the ok-button in the TabGroup
sequence, whereas decreasing the spacing puts it after the buttons.

O.k., the bible wouldn't be named like this, if it wouldn't help one
out - applying the TurnOffSashTraversal-Function at page 282 (BTW, you
must - as not explicitly mentioned - include the SashP.h file to link
XmIsSash in) to the pane gives back all freedom to treat the pane/sash
as one likes.

So this isn't a real problem, but I would be very interested to hear -
perhaps from someone who has got the Motif sources - *why* the TabGroup
arrangement does so heavily depend on the geometric properties of the
pane/sash. 

Thanks in advance, Josef

-- 
Josef Nelissen, Lehrstuhl fuer Angewandte Mathematik, insbesondere Informatik;
RWTH-Aachen, 5100 Aachen, Germany, Tel. 0241/8021060
jonas@beor.informatik.rwth-aachen.de
** In the beginning was the word, 2 bytes long, aligned on an even boundary. **