Submitted by Anonymous on Thu, 05/02/2002 - 08:04. Developers
I have a library based scrolled window input area. This was developed in early 1997.
It is totally data driven and dynamic. This works perfectly under 1.2 but
porting to 2.1.30 is proving a little difficult.
The 1.2 code does not work under 2.1.30.
The following code segment does not quite work. When I had a rowcol the problem
was that the first row ( form) was not attached to the top of the display area
RowCol widget, otherwise all display was OK.
On the advice from dbl, thank you, I changed this to a form widget,
with suitable resource changes as seen below.
The problem now is that while everything is attached correctly and scrolls
correctly but the title row is blanked out. It the line XtManageChild(form1[i]);
is omitted then the title row is visible but with form1[i] managed the row
exists but is devoid of text, even if explicity assigned post generation.
The widget `form` musts exist otherwise the first input row `form[1]` would not
be attached to anything and all that X protocol would be wandering around
aimlessly.
I have compared the text in O`Reilly`s 6A & 6B between my paper copies and the
downloaded "open source 2.1" copies. I might be just not seeing but I cannot
find anything that helps me.
So what have I not assigned or what should I have not assigned.
Thankyou in anticipation for any input as I admit I am a tad confused.
// FIRST WIDGET ON SCROLLED WINDOW
wdw =
/* XtVaCreateWidget("AN_EDIT_PANEL",xmRowColumnWidgetClass, */
XtVaCreateWidget("FORM_ROW",xmFormWidgetClass,
Scrolled window parent widget ,
XmNwidth, suitable width, /* dynamic */
XmNheight, suitable height , /* dynamic */
XmNx, 0 ,
XmNy, 0 ,
NULL);
/* FIRST widget - to hold column titles */
form =
XtVaCreateWidget("PANEL_FORM",xmFormWidgetClass,
wdw,
XmNverticalSpacing, 0, /* force to top of parent form widget `wdw` */
XmNtopAttachment, XmATTACH_FORM,
XmNleftAttachment, XmATTACH_FORM,
NULL);
i = 0;
if((disp = no_of_labels) > 0) {
a_k =0;
for(j=0;j < disp;j++) {
/* build of the managed widgets within `form`, in this case labels only*/
}
XtManageChild(form);
i = 1 ;
}
/* NOW OVER THE NUMBER OF DATA INPUT ROWS - GENERATE FORM WIDGETS AND
POPULATE WITH MIXED WIDGETS , I.E TEXT, LABEL, BUTTONS ETC */
for(;i form1[i] =
XtVaCreateWidget("FORM_ROW",xmFormWidgetClass,
(i==1) ? form form1[i-1] ,
XmNverticalSpacing, 20, /* NEEDED AS NOT USING ROWCOL */
XmNleftAttachment, XmATTACH_FORM,
XmNtopAttachment, XmATTACH_FORM,
NULL);
for(j=0,a_k=0;j < wdw_ptr->no_of_cols;j++) {
/* build of the managed widgets within `form[i]`, in this case
mixed widgets */
}
XtManageChild(form1[i]); /* if omitted labels row populated */
} /* WDW_LENGTH for loop */
XtManageChild(wdw);
I still think your treating the attatchments too lightly.
Your have
XmNtopAttachment, XmATTACH_FORM,
I as the attatchment of your form in the scrolled window. But the scrolled window is a widget. Also you haven`t yet created a form - that `s a indication your not going to be attatching to one.
The code will compile and your get weird things if attatchments are wrong. Count on it. You might even get something that looks ok but segfaults once in a while.
Its real simple you can`t attatch to something you haven`t created. If it is created, their is more than one option to attatch to it (ie, like ATTATCH_OPPOSITE). Its taken one at a time. (Now UIL and layout ramifications is something else - I have no clue about that.)
Looking in the code I have that has a menubar, a form widget area, and a scrolled window having a container that has a title area for the widgets in the container (but I`m using XmContainers, so XtSetArg (args[n], XmNdetailColumnHeading takes care of the headings). It uses
XtSetArg (args[n], XmNtopAttachment, XmATTACH_WIDGET); n++;
(I beleive pertinently) where the code your working on has XmATTATCH_FORM.
PS
Layouts attatchments can be gotten from xrdb to allow app-default changes; if you check the xrdb for it.
I`m not sure if you have a fallback_resource in the code or an old .Xdefault entry that would change widget attatchments in your code. You might give it a try.
For instance, I have
"*XmContainer.outlineColumnWidth 10cm"
as a "resource fallback". This gets used even though I don`t actaully set the detail for it in the interface code. Something to think about anyway.
Thanks Sparky,
As you may have seen in another set of notes I resolved the original RowCol problem.
It was an x,y set that in 1.2 was relative to the parent bulletin but in 2.2 is relative to the
top left corner of the scrolledWindow - as it should be. So my porting issues were completely
solved. Now I can look at the new 2.2 features. At first sight I do not like the ComboBox so
I will stick to the my current version. 99% of the motif code is in generic library functions driven
by compile and run time data sets, saves writting any code that way!
For academic interest I am still looking at my missing label line. The first form widget was created and was managed and
was visible if the other attached rows were not either created or managed. Indeed it appears blank when they are. I shall play with resource to try and understand this one fully. In the original SCO UNIX 5.0.5/6 1.2 system we do not have any segmentation or other core dump issue, we will have to wait and see for this Linux 2.2 version.
darryls@productcosting.com