Submitted by Anonymous on Wed, 04/24/2002 - 14:41. Developers
Hi! anyone out there,
I am porting an SCO UNIX Motif 1.2 to a Caldera Linux system using Motif 2.1.30
All has been reasonably OK -except
I have a scrolling input table constructed as
Bulletin -> scolled Window -> RowColumn -> Form -> row elements
The row elements are heterogeneous and can comprise of any combination of
text, labels, buttons and ComboBoxes.
The scrolled input area is displayed OK Except that the first line is not attached
to the top of the display are but offset by the equivalent of 5 rows.
I have tried to forced position at all levels by the use of Fraction base, Offsets ,
changes to ATTACH behavoir and singuarily failed to solve this problem.
Possible problem with Callbacks also but this may be dependent of solving this issue.
I wish to keep the construct if at all possible to maintain source level consistency
between the various ports.
Any help gratefully received and faithfully applied.
// cut down code to show basic structure of code.
/* the establishment of the scrolled wndow */
if((field_ptr-1)->type == OSL_SCROLL_BAR ) {
XtSetArg(arg_list[nargs], XmNverticalScrollBar, field_widgets[nfields-2]);
nargs++ ;
XtSetArg(arg_list[nargs], XmNhorizontalScrollBar, field_widgets[nfields-1]);
nargs++ ;
}
else {
/* scroll policy to auto */
XtSetArg(arg_list[nargs], XmNscrollingPolicy, XmAUTOMATIC);
nargs++ ;
}
XtSetArg(arg_list[nargs], XmNborderWidth, 1);
nargs++ ;
XtSetArg(arg_list[nargs], XmNscrollBarDisplayPolicy, XmAS_NEEDED /* XmSTATIC */);
nargs++ ;
XtSetArg(arg_list[nargs], XmNscrollBarPlacement, XmBOTTOM_RIGHT);
nargs++ ;
field_widgets[nfields] = XmCreateScrolledWindow(tmp_widget,
field_ptr->resource_name,arg_list,nargs);
if(field_ptr->sensitive != 4)
XtAddCallback(field_widgets[nfields],XmNtraverseObscuredCallback,
traverse_func,(caddr_t) tmp_widget);
// the window filling code
// ALL the first rows is always 100% LABELS
void set_scroll_element(Widget parent,col_str * col_ptr,int col, int row)
{
int err_cnt=0;
switch(col_ptr->type) {
case OSL_SYS_LABEL
case OSL_LABEL
fld[col][row] = XtVaCreateManagedWidget(col_ptr->message,
xmLabelGadgetClass, parent ,
XmNalignment, XmALIGNMENT_BEGINNING,
XmNeditable, False,
XmNtopAttachment, XmATTACH_FORM,
XmNbottomAttachment, XmATTACH_FORM,
XmNcursorPositionVisible, False,
XmNx, col_ptr->x,
XmNcolumns, col_ptr->lngth,
NULL);
break ;
ETC. ETc. ETC.
}
// Call backs
}
void set_scroll_window(int field_pos,fields *field_ptr,wdw_str * wdw_ptr)
{
int bad =0 ;
int i,j,repeat,a_k ;
int disp ;
int cols ;
int x1;
Arg arg_list[3];
extern Widget passed_widget ;
Widget form,wdw ;
/* the work window */
cols = wdw_ptr->no_of_labels;
if(cols < wdw_ptr->no_of_cols) cols = wdw_ptr->no_of_cols;
if(cols < disp) cols =disp;
wdw =
XtVaCreateWidget("AN_EDIT_PANEL",xmRowColumnWidgetClass,
(field_pos == -1) ? passed_widget
field_widgets[field_pos],
XmNwidth, field_ptr->width + field_ptr->solitary,
XmNx, field_ptr->x,
XmNy, field_ptr->y,
XmNresizeWidth,False,
XmNrubberPositioning,False,
XmNadjustLast,False /* True */,
XmNentryVerticalAlignment, XmALIGNMENT_CONTENTS_TOP,
XmNorientation,XmHORIZONTAL, /* was commented out 14/5/1997 */
XmNpacking,XmPACK_TIGHT,
#if 0
XmNnumColumns,cols,
#else
XmNnumColumns,WDW_LENGTH+1,
#endif
#if 0
/* various resources changes at all levels */
XmNtopAttachment, XmATTACH_FORM,
XmNbottomAttachment, XmATTACH_FORM,
XmNfractionBase,wdw_ptr->FractionBase,
XmNtopOffset,1, /* test DJS 22/4/2002 */
XmNtopPosition, 1, /* test DJS 22/4/2002 */
#endif
NULL);
if(field_ptr->bg_colour != NULL) {
XtSetArg(arg_list[0], XmNbackground,field_ptr->bg_colour);
XtSetValues(wdw,arg_list,1);
}
form =
XtVaCreateWidget("PANEL_FORM",xmFormWidgetClass,
wdw,
#if 0
XmNleftAttachment, XmATTACH_FORM,
XmNfractionBase,wdw_ptr->FractionBase,
XmNrubberPositioning,False,
XmNverticalSpacing,1, /* test DJS 23/4/2002 */
XmNtopOffset,1, /* test DJS 22/4/2002 */
XmNtopAttachment, XmATTACH_SELF,
XmNbottomAttachment, XmATTACH_FORM,
XmNtopPosition, 1, /* test DJS 22/4/2002 */
#endif
NULL);
i = 0;
if((disp = wdw_ptr->no_of_labels) > 0) {
a_k =0;
for(j=0;j < disp;j++) {
set_scroll_element(form,&(wdw_ptr->col_ptrs[j]),j+a_k,i) ;
}
XtManageChild(form);
i = 1 ;
}
for(;i // the input fields in similar form
XtManageChild(form);
}
XtManageChild(wdw);
}
If the RowColumn has only one child, the Form, then simply omit RowColumn from the hierarchy. Its functionality in that case is redundant. The Form is then a child of the ScrolledWindow, and attachments for the Form`s children are then made as constraint resources within the Form.
One tool that can help you figure out the Form constraints is at http//www.motifzone.com/tmd/articles/FormShow/info.html , "Debugging Form Constraints". There`s a sample debugging picture at http//www.motifzone.com/tmd/articles/FormShow/sample.gif . It came out of a moment of frustration. The code should be trivially recompilable for Motif 2.
(The Callback problems are separate.)
And, yes, the idea is that Motif is the same everywhere, so the
porting should be easy.
Too hard to read!
For problems of this sort, I do this
- write from the inside out. That is, I figure out each individual row and how it should behave. How should it initially appear? How should it resize? How should extra space be absorbed and vanish? Those characteristics determine the manager widget. In this case, XmForm is probably a better choice than XmRowColumn. And then how does that inner element interact with others? Again, the answers determine the manager. In this case, again, the XmForm is probably more useful than the XmRowColumn, despite the RowColumn`s inviting name.
- debug from the outside in. You can trivially set the widgets` backgrounds to different colors to see their extents, which helps figure out where the stretching is going on.
More input,
Thanks for the reponses dbl. I agree the schematic is a bit messy, comes from extracting relevent code segments and pasting them together. I will look at the areas you offered, thankyou.
The trivial case is indeed the one form widget as a child of the RowCol which is a chilc of the ScrolledWindow. It has this behavoir in all circumstances under this version of Motif.
The behavoir between forms in the none trivial case is 100% OK. It is "only" the attachment between the top of first form and thje top of the display area.
______________________________________________________________________________________________
| |
| |
| THE 2.2 GAP!! |
| |
| |
| Heading of the columns in a form, all labels |
| Combination of label, text, button and combo widgets |
| Combination of label, text, button and combo widgets |
| Combination of label, text, button and combo widgets |
| Combination of label, text, button and combo widgets |
| Combination of label, text, button and combo widgets |
| Combination of label, text, button and combo widgets |
| Combination of label, text, button and combo widgets |
| Combination of label, text, button and combo widgets |
| Combination of label, text, button and combo widgets |
| Combination of label, text, button and combo widgets |
| Combination of label, text, button and combo widgets |
| Combination of label, text, button and combo widgets |
| Combination of label, text, button and combo widgets |
| Combination of label, text, button and combo widgets |
| Combination of label, text, button and combo widgets |
etc
Having read the "Debugging Form Constraints" that dbl pointed me towards I suspect that it will no thelp solve this problem.
If I read it correctly it purpose to to help in the positioning of widgets within a form. A very usefull tool especially with heterogeneous layouts. This problem has `perfectly` positioned widgets within each form, each form is positioned perfectlly to its predecessor and to the sides and bottom of the RowCol widget. The only attachment problem is attaching the first widget to the top of the RowCol. In 1.2 the behavoir is as required.
I find it difficult to believe that this is a bug in 2.1.30/2.2 as someone else would have bumped into it. There has to be an interfering resource somewhere, or our code has worked by coincidence despite breaking rules under 1.2.
Despite the comments above I shall try FormShow in a test function to see if it contributes. I shall also try some get values on the first form widget on the basis that understanding why will inevitably lead to solution.
And I suggest you drop the XmRowColumn from the hierarchy.
Hi,
I have form attatchment problems like that when I`m applying the ultimately educated and correct answers (contrstrains, resources) to the wrong object.
For instance once I had a hell of a time trying to figure out why certain XmN details being applied to a scrolled window were not taking effect and even causing seg faults. I even had problems fitting a simple form together.
My fault wrong parent. Both objects had the `ability` to have the XmN details set. But after it all I realized that I was asking the wrong object to do things.
Try looking at the source. If their seems to be a rampant lack of support in the code for what your trying to do theirs a good chance your using the directions incorrectly.
As well, the layout manager won`t appreciate your correct specifications if the details are attatched to the wrong object.
BTW
I don`t think you can use "AS_NEEDED" if your using application defined scrolling. It seems the code can possibly define its scrollbars then use AS_NEEDED. This ins`t necessary you can get the widgets created automatically with a XtVaGet call.
I don`t know about "ETC ETC". You can`t attatch widgets in a homogenous fasion per say. What attatchments are necessary depends on where the widget is supposed to be with respect to the other widgets its touching. These may be parents or children depending on how the form is arranged or re-arranged.
The result is great a container that you don`t have to use a GUI to build that takes care of resizing itself, respecting neighbors (as opposed to static forms that have to be manually laid out).
I`m going to bet your attatchments are wrong and that SCO, somewhere, has a fix that is not in OpenMotif2.1.30.
I`d build a small stand-alone example app and get that working, then translate the working form`s solution into the bigger hack, myself.
It looks like your ATTATCH_FORM in set_scroll_window before you`ve even created a form. And where is any ATTATCH_WIDGET to the scrollw?
Are you sure you can tell a form *inside* a row/columnsthat`s *inside* a scrolled window (which has attatchment) to use SELF_ATTATCH? Because I thought that gave me a segfault once.
I`m not sure why you`d ever loop XtManageChild(form) on the same form. Seems to me I get the one and ony result the first time. Good thing Xm uses locking )
I`m thinking SCO`s code handled attatchment errors better?
P.S.
Anyway - if your working on Unixware[7.1]`s swiss army motif admin thing good luck! I just love those tools!
Status
Code 100% OK in 1.2 All behavoir as required and expected.
In 2.1.30 ( technically)
Removed the rowcolumn widget effect could position heading as required BUT massive
white space at the end of the row widgets, approximate size twice that of the input rows displayed.
But needed to control verticalSpacing directly and introduce a widget arrays to cater for the rows.
Do not know what effect this will have when seen through other screen resolutions and
application handlers such as Tarantella - time will tell. I suspect this will have to be suitably
externalised to accomodate display resolutions.
Solution reinserted the RowCol widget in Hierarchy but replaced with a form. Removed obsolete
args.
Result needed to calculate height explicitly but input visualisation now contained within the
required area.
Problem title row was blank. With data rows supressed title is seen and anchored
to top of the scroll Window area. With rows in but "blank", title is seen at the bottom of
the area. Can`t think why, yet, it should leave a space but make it invisible.
Still would like to understand why 1.2 and this release behave so differently.
Thanks for the inputs.
As in the DrawingWidget issue above I found an explicit XmNx,y which when forced
locally to 0 all was fine AND with the ROWColumn widget so control now automatic
etc etc.
Still does show that 2.1.30 is far more robust than 1.2 as 1.2 let this through without
an error.
Action closed - result all now ported.
Thanks for the inputs.
As in the DrawingWidget issue above I found an explicit XmNx,y which when forced
locally to 0 all was fine AND with the ROWColumn widget so control now automatic
etc etc.
Still does show that 2.1.30 is far more robust than 1.2 as 1.2 let this through without
an error.
Action closed - result all now ported.