Errata

Motif Programming Manual, Vol 6A

Errata for Motif Programming Manual, Vol 6A

Submit your own errata for this product.

The errata list is a list of errors and their corrections that were found after the product was released.

The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.

Color Key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update

Version Location Description Submitted by Date submitted
Printed Page 207
In the third line,

"proint"

should read:

"point"

 Anonymous   
Printed Page 246
The description if attachments for WIDGET-2 are really those for

WIDGET-3 and vice versa.

 Anonymous   
Printed Page 251
First of all, Example 8-3 references Fig. 8-2 (bottom of pg. 250),

then states that its output is shown in Fig. 8-6 (bottom of pg. 251).
In these two figures Widgets 2 and 3 are reversed.
If Fig. 8-2 is the correct reference, then the comment in the example for
Widget "three"'s XmNleftAttachment should state the "...right side of
"one"", not the "...left side of "one"".
If Fig. 8-6 is the correct reference, then the code in this example for
Widgets "two" and "three" is reversed, in addition to the comment typo
stated above.


[Chapter 7] I found a bug in the example program ch07/help_text.c
given in the = "Motif programming manual" for OSF/Motif Release 1.2
Volume 6A, Motif edition. To simulate this:

1. Run help_text program
2. Invoke "On context" from Help menu.
3. Resizie this window from right to left almost near wrap around,The =
color changes and in promt displays "segmentation fault (core dumped)". =
and application vanishes.
4. This is more frequent if I comment line 255 and line 256 which sets =
the horizontal and vertical scroll resources.
5. It is with fvwm1.24r version of window manager and not observed in =
fvwm2.2 version.

I am using Motif libraries 2.1 version.

On page 492 of 6A_book.pdf the following lines of example code appear:

...Begin Snip...
/* create the List items */
str_list = (XmStringTable) XtMalloc (count * sizeof (XmString *));

for (i = 0; i < count; i++)
str_list[i] = XmStringCreateLocalized (colors[i]);

/* create the combobox */
n = 0;
XtSetArg (args[n], XmNitems, str_list); n++;
XtSetArg (args[n], XmNitemCount, count); n++;
combo = XmCreateDropDownList (toplevel, "combo", args, n);

for (i = 0; i < n; i++)
XmStringFree (str_list[i]);
XtFree ((XtPointer) str_list);
...End Snip...

I belive the second for loop is wrong, n is the number of arguments not the
number of items in str_list. If I understand the code correctly the for loop
should read as follows:

for (i = 0; i < count; i++)
XmStringFree (str_list[i]);

 Anonymous   
Printed Page 537-538
Example Code 15-5

The error is in example 15-5, the check_days() function, where the value of
'leap' is calculated (lines 37 and 66). The code sets 'leap' true if *and
only if* the year is an integral multiple of 400. (Try 1980: "(((1980 % 4)
== 0) ? ((1980 % 400) == 0 ? 1 : 0) : 0)" ==> "((0 == 0) ? (380 == 0 ? 1 :
0) : 0)" ==> "(1 ? (0 ? 1 : 0) : 0)" ==> "(0 ? 1 : 0)" ==> "0". It's wrong.)

A correct version of the code is: "leap = ((year % 4) == 0 ? ((year % 100)
== 0 ? ((year % 400) == 0 ? 1 : 0) : 1) : 0);". I would also accept the
somewhat shorter version, "leap = ((year % 4) ? 0 : ((year % 100) ? 1 :
((year % 400) ? 0 : 1)));".

{chapter 18} Section 5
The other piece of code which I question is in the callbacks for Text
widget modification, chapter 18, section 5, under the headings "Preventing
Text Modification" and "Handling Text Deletion" (page 576). In these
sections, you propose comparing the values of 'cbs->startPos' and
'cbs->currInsert' to determine whether text is being deleted. Although
this is true for a simple backspace operation, there are other cases when
this is not true (for example, simply pressing the Delete key). In
addition, in the code example 18-11 "check_zip", you add
XmTextGetLastPosition(text_w) to cbs->text->length to make sure the
resulting length won't exceed 5 characters. I have in fact written a
program that did a similar check, and disallowed the modification
(cbs->doit = False) if the length would exceed the limit. The program did
not work as expected. Here's why:

It is possible for a single modification to both delete old text and insert
new text at the same time. There are two cases when this will happen.
First, if the user has highlighted some text, then types in a character,
that character will replace the selected text. Second, if the application
calls XmTextSetString(), the entire value of the text field will be
replaced with the new string. In my program, I was adding the length of
the old value to the length of the new value, found the sum to be too long,
and refused the change; even though the new value was perfectly acceptable.

A much better means of determining whether text is being deleted or
inserted is to separately test the difference between cbs->endPos and
cbs->startPos, and check the value of cbs->text->length. A difference
between cbs->endPos and cbs->startPos indicates the amount (and location)
of text being deleted. The value of cbs->text->length indicates the amount
of text being inserted. Both values may be non-zero.

Just now, I've noticed an error in the print (1st) edition of the Motif
Reference Manual, which was only halfway corrected in this (3rd) edition.
The structure members for XmTextVerifyCallbacStruct and
XmTextVerifyCallbacStructWcs incorrectly show the two-word member names
"current_insert", "new_insert", "start_pos", and "end_pos". In the PDF
version, XmTextVerifyCallbacStruct has the correct member names, but
XmTextVerifyCallbacStructWcs still has the incorrect names. Also, in
XmTextVerifyCallbacStructWcs, the last member name is not properly
separated from its data type by a space: "XmTextBlockWcstext;".

 Anonymous   
Printed Page 726

Line 7 (including space line) reads:

"&event"

for the last parameter of the XmTrackingEvent call. It should read:

"event"

 Anonymous   
Printed Page 736
1st paragraph - code

Vol 6A pg 735-736 Section 21.1.2 Context-sensitive Help

- code sample declares:

XEvent *event;

and then calls XmTrackingEvent( toplevel, cursor, True, &event);

but XmTrackingEvent doesn't take a _XEvent** ... it takes a _XEvent*

Am I doing something wrong? Help. I'm using a SUN sparc compiler 4.2

-------
sent in by - Anthony Taiani:

The following are comments/suggestion regarding a particular
section of the Motif Programming Manual.

In Example 7-2, The modify_btn.c program, Pages 225-229,
regarding the setting of the XmNuserData resource in the
PromptDialog widget, programmatically, when the user selects either
of the buttons in the ToggleBox, the XmNuserData resource is set
ultimately through the functionality of XmVaCreateSimpleRadioBox.
In the Motif Reference Manual, Page 566, in the description of XmVaCreateSimpleRadioBox, it states

-----------------------------------------------------------------------------------
When the callback is invoked, the button number of the button whose value has changed is passed to the callback in the client_data
parameter.
-----------------------------------------------------------------------------------

The client data parameter of toggle_callback, through the functionality of XmVaCreateSimpleRadioBox, holds the selected toggle value which is
ultimately stored in the XmNuserData resource. But this fact is not offered in any part of the explanation of the setting of the XmNuserData resource
in Example 7.2 .

In the initial comment of the pushed function, it states

/* pushed() --the callback routine for the main app's pushbuttons.
** Create a dialog that prompts for a new button name or color.
** A RadioBox is attached to the dialog. Which button is selected
** in this box is held as an int (0 or 1) in the XmNuserData resource
** of the dialog itself. This value is changed when selecting either
** of the buttons in the ToggleBox and is queried in the dialog's
** XmNokCallback function.
*/

I would change this to

/* pushed() --the callback routine for the main app's pushbuttons.
** Create a dialog that prompts for a new button name or color.
** A RadioBox is attached to the dialog. Which button is selected
** in this box is held as an int (0 or 1) in the client data
** parameter of toggle_callback() through the functionality of
** XmVaCreateSimpleRadioBox(), and later stored in the
** XmNuserData resource of the dialog itself. The XmNuserData
** resource is changed when selecting either of the buttons in the
** ToggleBox, and is queried in the dialog's XmNokCallback function.
*/

In a comment of the pushed function, it states

-----------------------------------------------------------------------------------
/* Create the dialog -- the PushButton acts as the DialogShell's
** parent (not the parent of the PromptDialog). The "userData"
** is used to store the value
*/
-----------------------------------------------------------------------------------

I would change this to

-----------------------------------------------------------------------------------
/* Create the dialog -- the PushButton acts as the DialogShell's
** parent (not the parent of the PromptDialog). XmNuserData
** is used to globally store the toggle buttons value. Initialize
** XmNuserData to a 0 value corresponding to the
** radio_box initialization of 0 later in the code.
*/
-----------------------------------------------------------------------------------

I would add the comment regarding XmNuserData initialization
because XtSetArg (args[n], XmNuserData, 0);
initializes XmNuserData to the initial value of 0
corresponding to the initial toggle value of 0 for the
radio box defined in the code

toggle_box = XmVaCreateSimpleRadioBox (dialog,
"radio_box", 0, toggle_callback, .

In fact, in a previous edition of Motif Programming Manual (July 1992),
this code included an informative comment.

toggle_box = XmVaCreateSimpleRadioBox (dialog,
"radio_box", 0 /* initial value */, toggle_callback, .

I would reintroduce and expand the /* initial value */ comment in the code to

toggle_box = XmVaCreateSimpleRadioBox (dialog,
"radio_box", 0 /* initial toggle value */, toggle_callback, .

In a later section of the pushed function, it states
-----------------------------------------------------------------------------------
/* Create a toggle box -- callback routine is toggle_callback() */
btn1 = XmStringCreateLocalized ("Change Name");
btn2 = XmStringCreateLocalized ("Change Color");
toggle_box = XmVaCreateSimpleRadioBox (dialog,
"radio_box", 0, toggle_callback,
XmVaRADIOBUTTON, btn1, 0, NULL, NULL,
XmVaRADIOBUTTON, btn2, 0, NULL, NULL,
NULL);
-----------------------------------------------------------------------------------

I would extend the comment in this section of code to include a comment regarding the functionality of XmVaCreateSimpleRadioBox storing the button number of the button, whose value has changed, in the client data parameter of the callback function.

-----------------------------------------------------------------------------------
/* Create a toggle box -- callback routine is toggle_callback().
** XmVaCreateSimpleRadioBox() stores the button number of the
** toggle button, whose value has changed, in the client data
** parameter of the toggle_callback() callback function.
*/
btn1 = XmStringCreateLocalized ("Change Name");
btn2 = XmStringCreateLocalized ("Change Color");
toggle_box = XmVaCreateSimpleRadioBox (dialog,
"radio_box", 0 /* initial toggle value */, toggle_callback,
XmVaRADIOBUTTON, btn1, 0, NULL, NULL,
XmVaRADIOBUTTON, btn2, 0, NULL, NULL,
NULL);
-----------------------------------------------------------------------------------

In the comment of the toggle_callback function, it states

-----------------------------------------------------------------------------------
/* callback for the items in the toggle box -- the "client data" i
** the item number selected. Since the function gets called whenever
-----------------------------------------------------------------------------------

I would change this to

-----------------------------------------------------------------------------------
/* callback for the items in the toggle box -- the "client data" is
** the item number selected. The selected value is stored in the
** "client data" parameter of toggle_callback() through the functionality
** of XmVaCreateSimpleRadioBox(). Since the function gets called
** whenever
-----------------------------------------------------------------------------------

Later, in the description of the functionality of the XmNuserData resource,
it states

-----------------------------------------------------------------------------------
We add a RadioBox as the work area child of the PromptDialog. The ToggleButtons in the RadioBox indicate whether the input text is supposed to change the label of the PushButton or its text color. To determine which of these attributes to change, we use the callback routine toggle_callback().

Rather than storing the state of the RadioBox in a global variable, we store the value in the XmNuserData resource of the dialog widget. Using this technique, we can retrieve the value any time we
-----------------------------------------------------------------------------------

I would change this to

-----------------------------------------------------------------------------------
We add a RadioBox as the work area child of the PromptDialog. The ToggleButtons in the RadioBox indicate whether the input text is supposed to change the label of the PushButton or its text color. To determine which of these attributes to change, we use the callback routine toggle_callback().

Toggle_callback(), through the functionality of XmVaCreateSimpleRadioBox(), holds the state of the RadioBox in its client data parameter. Rather than storing the state of the RadioBox in a global variable, toggle_callback() stores the value in the XmNuserData resource of the dialog widget. Using this technique, we can retrieve the value any time we
-----------------------------------------------------------------------------------

 Anonymous