From: jan@PANDONIA.CANBERRA.EDU.AU (Jan Newmarch)
Newsgroups: comp.windows.x.motif
Subject: Motif FAQ - repost
Date: 19 Aug 92 14:57:29 GMT
Distribution: inet
Organization: The Internet

Ooops - I goofed in the last Motif FAQ and posted the July edition again
rather than the August one.  Instead of reposting the whole thing again,
below are the changed/new articles from July to August.  Sorry about that.



-----------------------------------------------------------------------------
Subject:  6)*  What versions of Motif are there?
[Last modified: August 92]

Answer: Motif 1.0 is based on the R3 toolkit.  There are patch releases to
1.0: 1.0.1, 1.0.A, 1.0.2 and 1.0.3, 1.0.4, 1.0.5. 1.0.A was a fairly major
patch, as it involved a complete re-engineering of UIL and Mrm.  Almost
everyone who has 1.0.x has either 1.0.A or 1.0.3.  There are not expected to
be further patches to 1.0.

Motif 1.1 is based on the R4 toolkit.  The current version is Motif 1.1.0,
plus a couple of patches available to full support contract holders. Motif
1.1.1 has been released as a patch to licensees with Full Support or Technical
Update service.  Motif 1.1.2 is a patch release which contains the necessary
changes to fix over 80 bugs reported against Motif. It is available to support
contract holders (including both full support and update service).  The 1.1.3
release fixes a further 150 bugs and is available from August 1991 to support
contract holders (including both full support and update service).  1.1.4
offers X11R5 support, but is not an X11R5 product.  1.1.5 was released in June
92 to licensees who hold a Motif Full Support or Update Support contract

Motif 1.2 was released in April 1992 and is based on the X11R5 toolkit.  It
offers increased compatibility with international standards,  PC-style
behavior and binary compatibility with OSF/Motif 1.1 applications.  New
features include drag-and-drop, tear- off menus, toolkit enhancements and new
documentation.  toolkit.  The code is totally ANSI C.  OSF distributes a 10
pages sheet entitled "OSF/Motif R1.1 to R1.2: detailed overview of changes",
which is available from OSF Motif direct channels.  (617-621-7300 or email
direct@osf.org)

From dbrooks@osf.org: "Motif 2.0 will ship well before the sun burns out,
unless we decide to change the name first, and will contain a free plastic
spaceman in every box."

-----------------------------------------------------------------------------
Subject: 24)*  How can I turn off the Motif window manager functions from the
system menu?
[Last modified: August 92]

Answer: The user of an application can control functions in the system menu
for an application using the mwm resource clientFunctions:

        mwm.application_name.clientFunctions: -resize -close


Answer: The writer of an application can only remove items.  Be warned that
your users will probably gnash their teeth, swear furiously at your product
and stop using it if they discover that you have done this.  (Especially if
you have removed the Close button, your application has hung and it has taken
up all of memory and swap so it can't be killed.) Much better is to catch the
action gracefully as in the next question.

        XtVaGetValues(shell, XmNmwmFunctions, &int_val, NULL);
        int_val &= ~(MWM_FUNC_CLOSE | MWM_FUNC_ALL);
        XtVaSetValues(shell, XmNmwmFunctions, int_val, NULL);


-----------------------------------------------------------------------------
Subject: 28)*  What prototyping tools are there to generate Motif code?
[Last modified: August 92]

Answer: [An FAQ is for "personal opinions" on these tools.  I don't think it
is appropriate to give such opinions through this particular posting, so I
haven't included any.]

`Prototyping tools' come in two forms: those that can be used to design the
interface only (GUI builder), and those that go beyond this to give support
for application code (User Interface Management Systems).  There are a number
of commercial and non-commercial tools of both kinds that will support the
Motif interface.  They include:

GUI builders:

Builder Xcessory
X Build
ExoCODE/xm


UIMS:

WINTERP
ALEX
Widget Creation Library
UIMX
Serpent
TeleUse
X-Designer
XFaceMaker2
MOTIFATION
MetaCard


Some contact addresses are:

WINTERP: You may obtain the current source, documentation, and examples via
anonymous ftp from host export.lcs.mit.edu: in directory contrib/winterp you
will find the compress(1)'d tar(1) file winterp.tar.Z. If you do not have
Internet access you may request the source code to be mailed to you by sending
a message to winterp-source%hplnpm@hplabs.hp.com or hplabs!hplnpm!winterp-
source.

Serpent: The S/W is free (anonymous ftp) from ftp.sei.cmu.edu.  For more info
contact erik/robert at serpent-info@sei.cmu.edu.

TeleUse: In the U.K., send mail to xtech@unipalm.co.uk or call +44 954 211862.
In the US contact Telesoft at:

TeleSoft, 5959 Cornerstone Court West, San Diego, CA 92121-9891
             Phone: +1 619-457-2700
                    +1 619-452-1334 Fax
             Email: guisales@telesoft.com (Sales),
                    guisupport@telesoft.com (Customer Support)


Builder Xcessory from ICS.  More details are available by sending a request to
info@ics.com.  Address: ICS Inc., 201 Broadway, Cambridge MA 02139, Tel. (617)
621-0060, Fax. (617) 621-9555

X-Designer: From Imperial Software Technology in the UK.  Email address is
sales@ist.co.uk.  (+44) 743 587055

Recently, V.I. Corporation have become the distributor for the X-Designer
product in the United States.  In addition, IST and V.I. Corporation have
developed a product called DVX-Designer that merges X-Designer with their GUI
product called DataViews.  Other merged products are in the works.  For more
information, people can contact:

        V.I. Corporation
        47 Pleasant Street
        Northampton, MA  01060
        Phone: (413) 586-4144
        Fax: (413) 586-3805
        Email: vi@vicorp.com


ExoCODE/xm: From Expert Object Corp., 7250 Cicero Avenue, Lincolnwood, IL
60646 (708)676-5555.

X Build: From Nixdorf Computer (Waltham, MA) xbuild@nixdorf.com


ExoCode: From EXOC (Chicago, IL)

UIMX: Visual Edge Software Limited, 3870 Cote Vertu, St Laurent, Quebec, H4R
1V4, Phone: (514) 332-6430, Fax:   (514) 332-5914, or: Visual Edge Software
Ltd., 101 First Street, Suite 443, Los Altos, CA 94022, Phone: (415) 948-0753,
Fax:   (415) 948-0843

The Widget Creation Library: The distribution is available in several ways.
The preferred approach it for you to get the compressed tar file using
anonymous ftp from:

    export.lcs.mit.edu    (18.30.0.238) /contrib/Wcl.1.06.tar.Z


XFaceMaker2: NSL -  Non Standard Logics S.A., 57-59, rue Lhomond, 75005  Paris
- France, Phone: +33 (1) 43.36.77.50, Fax:   +33 (1) 43.36.59.78 email:
requests@nsl.fr or requests%nsl.fr@inria.fr for information.

Their North American office: Non Standard Logics, Inc., 4141 State Street,
Suite B-11, Santa Barbara CA 93110, Tel: 805 964 9599, Fax: 805 964 4367


MOTIFATION: AKA EDV, Universitaetsstrasse 125, 4630 Bochum, Germany, Tel: +49
(0) 234 / 33397-0, Fax: +49 (0) 234 / 33397-40


ALEX: For more information contact Michael Karliner on (+44) 81 566 2307 or
E-mail to alex@s-strat.co.uk.  ALEX Technologies, Waterman's Yard, 32a The
Mall, Ealing, London W5, UK.

MetaCard: MetaCard 1.0 is supported on five popular UNIX/X11 platforms: SPARC,
Sun3, DECstation, HP-9000/300, and SCO ODT.  An HP-9000/700 port is underway
and should be available by the end of July.  [They] plan to support IBM
RS/6000, SGI Iris, and DG AViiON sometime fall '92.  For more information, or
to receive a free save-disabled but licensable copy of MetaCard, email to
info@metacard.com or call 303- 447-3936.  If you have anonymous FTP access to
the Internet, you can download the current engines, documentation, and an
unlicensed Home stack from ftp.metacard.com (128.138.213.21), directory
MetaCard.  Commercial users can get MetaCard from world.std.com
(192.74.137.5), directory pub/Metacard.  If you don't have an anonymous ftp
access, you can also download MetaCard from The World using kermit or xmodem
from the ~ftp/pub/MetaCard directory.  Sign up by calling 617-739-0202 (voice)
or via modem by dialing 617-739-9753 (7 bits even parity) and logging in as
new.

-----------------------------------------------------------------------------
Subject: 50)+ Can I have multi-line items in a list?
[Last modified: August 92]

Answer: Motif 1.0 and 1.1 both have problems with multi-line items in a list.
They should work okay in Motif 1.2.

-----------------------------------------------------------------------------
Subject: 74)+ What is the best way to create popup menus?
[Last modified: August 92]

Susan Murdock Thompson (from OSF): In general, create a popupMenu as the child
from which you will be posting it from (ie: if you have a bulletinBoard with a
PushButton in it and want MB2 on the pushButton to post the popupMenu, create
the popupMenu as a child of the pushButton).  [This parent-child relationship
seems to make a big difference in the behavior of the popups.]  Add an event
handler to handle buttonPress events.  You'll need to check for the correct
button (what you've specified menuPost to be) before posting the menu.

To create a popup that can be accessible from within an entire client window,
create it as the child of the top-most widget (but not the shell) and add
event handlers for the top-most widget and children widgets.

ie:

{
  ....

  XtManageChild(rc=XmCreateRowColumn(Shell1, "rc", NULL, 0));
  XtManageChild(label = XmCreateLabel(rc, "label", NULL, 0));
  XtManageChild(text = XmCreateText(rc, "text", NULL, 0));
  XtManageChild(pushbutton = XmCreatePushButton(rc, "pushbutton", NULL, 0));

  n = 0;
  XtSetArg(args[n], XmNmenuPost, "<Btn3Down>"); n++;
  popup = XmCreatePopupMenu(rc, "popup", args, n);

  XtAddEventHandler(rc, ButtonPressMask, False, PostMenu3, popup);
  XtAddEventHandler(text, ButtonPressMask, False, PostMenu3, popup);
  XtAddEventHandler(label, ButtonPressMask, False, PostMenu3, popup);
  XtAddEventHandler(pushbutton, ButtonPressMask, False, PostMenu3, popup);

  XtManageChild(m1 = XmCreatePushButton(popup, "m1", NULL, 0));
  XtManageChild(m2 = XmCreatePushButton(popup, "m2", NULL, 0));
  XtManageChild(m3 = XmCreatePushButton(popup, "m3", NULL, 0));

  XtAddCallback(m1, XmNactivateCallback, SayCB, "button M1");
  XtAddCallback(m2, XmNactivateCallback, SayCB, "button M2");
  XtAddCallback(m3, XmNactivateCallback, SayCB, "button M3");
  ...
}

/* where PostMenu3 is ... */

PostMenu3 (w, popup, event)
Widget w;
Widget popup;
XButtonEvent * event;
{
  printf("menuPost = 3, button %d0, event->button);

  if (event->button != Button3)
    return;
  XmMenuPosition(popup, event);
  XtManageChild(popup);
}



-----------------------------------------------------------------------------
Subject: 75)+ How do popup menus work?
[Last modified: August 92]

Answer:

When a popup menu is created as the child of a widget the menu system installs
a translation on the parent of the popup and descendants with an action which:
(1) when 3-rd button (the default for the menuPost resource) is pressed the
cursor changes and the mouse is grabbed for 5 seconds; (2) disables event
handlers on the descendants and the handlers are never called; (3) an event
handler installed on the parent works fine.

It is done so that the correct event handler will (in fact) be called.  There
is a grab with owner_events true.  The grab is released by a timer,  but
normally the posted menu shell puts up it's own grab.

If you only have widgets then you can use the subwindow field in the event to
identify the original widget.  If you have gadgets or other data that you want
to change the menu for (or use a specific menu for) then you must do a walk of
the parent's children to find the best match.

One thing to beware of is that even with the grab,  because the menu system
does a grab with owner events true, you must either have an event handler, or
nothing that will use the event on each widget in the hierarchy of the menu's
parent.  If a child widget has another event handler for button down, it may
swallow the event and do something else.



-----------------------------------------------------------------------------
Subject: 76)+ Should I use translation tables or actions for popup menus?
[Last modified: August 92]

Answer: The original goal of popupMenus was that the user would not have to
specify an event handler to manage popupMenus; however, that did not become
reality.  Larry Rogers wrote:

> There appear to be two ways to manage popup menus.  I
> am curious what the correct way would be:

> 1.  Change the translation table of the widget with the
>    popup child to popup the menu.  Note that this does
>    not currently working for many widgets, because aug-
>    menting their translations, even for augment breaks
>    the widget.

> 2.  Add an event handler at creation to the widget; then
>    determine if the event that caused the event handler
>    to be called is the current button being used by the
>    menu as its activation button.

Susan Murdock Thompson (from OSF) replied: *Theoretically, you should be able
to do both.*  Our documentation says use event handlers.  Our tests for the
toolkit use event handlers and for UIL use translations.  (Although I tried an
event handler with a UIL test and it works).

-----------------------------------------------------------------------------
Subject: 77)+ What are the known bugs in popup menus?
[Last modified: August 92]

Answer: As at Motif 1.1.4, the bugs for which an OSF PIR exists are:

   (3)  Menus not being sticky (ie: posted on a Btn CLICK)  [ Note:this
        problem occurs with OptionMenus as well]  (PIR 3435)

   (6)  Destroying a widget with an associated popupMenu results in
        "Warning: Attempt to remove non-existant passive grab"         (PIR
2972)

   (7)  Current documentation insufficient regarding requirements for
        success in using PopupMenus.  (PIR 3433)


-----------------------------------------------------------------------------
Subject: 78)+ Can I have multiple popup menus on the same widget?
[Last modified: August 92]

Answer: If you want to have several popups (activated by different mouse
buttons) on the same widget..., well, that doesn't work yet.

If you want to have several popups on different children... that works.  But
don't put a popup on the parent (manager) widget, or it will rule!


-----------------------------------------------------------------------------
Subject: 81)* How can I have a modal dialog which has to be answered before
the application can continue?
[Last modified: July 92]

Answer: The answer depends on whether you are using the Motif window manager
mwm or not.  Test for this by XmIsMotifWMRunning.

The window manager mwm knows how to control event passing to dialog widgets
declared as modal. If the dialog is set to application modal, then no
interaction with the rest of the application can occur until the dialog is
destroyed or unmanaged.

Use the appropriate code in the following program.  There is followup
discussion after the program.


/* Written by Dan Heller.  Copyright 1991, O'Reilly && Associates.
 * This program is freely distributable without licensing fees and
 * is provided without guarantee or warranty expressed or implied.
 * This program is -not- in the public domain.  This program is
 * taken from the Motif Programming Manual, O'Reilly Volume 6.
 */

/*
 * ask_user.c -- create a pushbutton that posts a dialog box
 * that asks the user a question that requires an immediate
 * response.  The function that asks the question actually
 * posts the dialog that displays the question, waits for and
 * returns the result.
 */
#include <X11/Intrinsic.h>
#include <Xm/DialogS.h>
#include <Xm/SelectioB.h>
#include <Xm/RowColumn.h>
#include <Xm/MessageB.h>
#include <Xm/PushBG.h>
#include <Xm/PushB.h>

XtAppContext app;

#define YES 1
#define NO  2

/* main() --create a pushbutton whose callback pops up a dialog box */
main(argc, argv)
char *argv[];
int argc;
{
    Widget parent, button, toplevel;
    XmString label;
    void pushed();

    toplevel = XtAppInitialize(&app, "Demos",
        NULL, 0, &argc, argv, NULL, NULL, 0);

    label = XmStringCreateSimple("/bin/rm *");
    button = XtVaCreateManagedWidget("button",
        xmPushButtonWidgetClass, toplevel,
        XmNlabelString,          label,
        NULL);
    XtAddCallback(button, XmNactivateCallback,
        pushed, "Remove Everything?");
    XmStringFree(label);

    XtRealizeWidget(toplevel);
    XtAppMainLoop(app);
}

/* pushed() --the callback routine for the main app's pushbutton. */
void
pushed(w, question)
Widget w;
char *question;
{
    if (AskUser(w, question) == YES)
        puts("Yes");
    else
        puts("No");
}

/*
 * AskUser() -- a generalized routine that asks the user a question
 * and returns the response.
 */
AskUser(parent, question)
char *question;
{
    static Widget dialog;
    XmString text, yes, no;
    static int answer;
    extern void response();

    answer = 0;
    if (!dialog) {
        dialog = XmCreateQuestionDialog(parent, "dialog", NULL, 0);
        yes = XmStringCreateSimple("Yes");
        no = XmStringCreateSimple("No");
        XtVaSetValues(dialog,
            XmNdialogStyle,        XmDIALOG_APPLICATION_MODAL,
            XmNokLabelString,      yes,
            XmNcancelLabelString,  no,
            NULL);
        XtSetSensitive(
            XmMessageBoxGetChild(dialog, XmDIALOG_HELP_BUTTON), False);
        XtAddCallback(dialog, XmNokCallback, response, &answer);
        XtAddCallback(dialog, XmNcancelCallback, response, &answer);
        /* if the user interacts via the system menu: */
        XtAddCallback(dialog, XmNpopdownCallback, response, &answer);
    }
    text = XmStringCreateSimple(question);
    XtVaSetValues(dialog,
        XmNmessageString,      text,
        NULL);
    XmStringFree(text);
    XtManageChild(dialog);
    XtPopup(XtParent(dialog), XtGrabNone);

    /* while the user hasn't provided an answer, simulate XtMainLoop.
     * The answer changes as soon as the user selects one of the
     * buttons and the callback routine changes its value.  Don't
     * break loop until XtPending() also returns False to assure
     * widget destruction.
     */
    while (answer == 0 || XtAppPending(app))
        XtAppProcessEvent(app, XtIMAll);
    return answer;
}

/* response() --The user made some sort of response to the
 * question posed in AskUser().  Set the answer (client_data)
 * accordingly and destroy the dialog.
 */
void
response(w, answer, reason)
Widget w;
int *answer;
XmAnyCallbackStruct *reason;
{
    switch (reason->reason) {
        case XmCR_OK:
            *answer = YES;
            break;
        case XmCR_CANCEL:
            *answer = NO;
            break;
        default:
            *answer = NO;
            return;
    }
}



If you aren't running a window manager that acknowledges this hint, then you
may have to grab the pointer (and keyboard) yourself to make sure the user
doesn't interact with any other widget.  Change the grab flag in XtPopup to
XtGrabExclusive, and XtRemoveGrab(XtParent(w)) to the response() function.


-----------------------------------------------------------------------------
Subject: 97)* Is there a C++ binding for Motif?
[Last modified: August 92]

Answer: The University of Lowell had a C++ binding.  The software is available
on any system running X11R3. Currently it is available for both the GNU's C++
compiler g++ v 1.37.1 and the AT&T C++ v 2.0 translator. They do not support
this anymore (lack of funds).  The software is available through ftp
129.63.1.1 in file graphics/MotifC++/Motif1.1-g++.tar.Z A bug fixed version of
the binding can be found at decuac.dec.com (192.5.214.1) for anonymous ftp in
pub/X11/motif++.03.dec.91.tar.Z. This includes some somewhat useful test-
programs. This has also been upgraded to full X11R4 & Motif 1.1.4 support

Or, upon request, by e-mail at the address below, which currently also is the
support/questions/bug-report address.

Ronald van Loon (rvloon@cv.ruu.nl) 3DCV Group, Utrecht, The Netherlands.




Answer: WWL is a library which defines C++ classes around X Toolkit Widgets.
It is intended to simplify the task of C++ code writers when using the Toolkit
by providing them with C++ objects, methods, type checking and several utility
functions and classes.

WWL has been tested under SunOs4.0.3 on sun3 and sun4, HPUX version 6.5 and
7.0 and Ultrix 4.0 on DECstation 3100 and 5000. It is expected to work on most
other UNIX systems without too many problems.

WWL is distributed as a tar file with all the source, documentation and
example. The file is available using anonymous ftp from

        export.lcs.mit.edu (18.30.0.238   contrib/WWL-1.0.tar.Z
        lri.lri.fr (129.175.15.1)      pub/WWL-1.0.tar.Z


Answer: Rogue Wave Software has announced a C++ class library for Motif called
View.h++.  It encapsulates 100% of Motif and X-Intrinsics.  It encapsulates
OSF/Motif, it doesn't emulate OSF/Motif.  View.h++ also includes Rogue Waves
Tools.h++, the foundation class library that is included with many C++
compilers.  If you would like information on View.h++ call or fax

   Voice (503) 754-3010
   Fax   (503) 757-6650
   Rogue Wave Software
   P.O. 2328
   Corvallis, OR 97339


Answer: From Andreas.Baecker@gmd.de: The GINA++ application framework contains
an encapsulation of the OSF/Motif widg et classes and the Xt functionality
into C++ classes. Its functionality is comparab le to that of the ULowell
binding and the WWL. Additionally, it provides an easy-to -use framework for
modeling new composite and primitive widget classes, plus an application
framework similar to ET++ or MacApp build on top of it. The binding may be
used independently from the framework classes. GINA++ is available through
anonymous ftp from ftp.gmd.de [129.26.8.90] in the directory /gmd/ginaplus.
Documentation about the Motif binding has been published in the X Resource
Journ al, Number 2, 1992, Pages 106-130. The binding compiles with AT&T C++
2.1 and GNU G+ + 2.1 and has been tested on SunOS 4.1.[12], X11R4 and Motif
1.1.3.

Answer: From Paul Felix (felix@ahpcrc.umn.edu): Motif++ is a library that
defines C++ class "wrappers" for the widgets defined in the OSF/Motif-1.1
widget library. Motif++ is also an application toolkit that provides other
tools in conjunction with the widget wrapper classes.

Motif++ is very similar to other public domain widget libraries such as The
Widget Wrapper Library (WWL) and the C++ Binding for OSF/Motif developed at
the Univeristy of Lowell. The two latter libraries are the result of much
larger efforts.

Availability:

directory: pub/Motif++
files:
        Motif++.tar.Z      - all the source (including xmedit, xmcolors
                             and Wcl)
        xmedit.sgi.tar.Z   - the text editor compiled on SGI
        xmcolors.sgi.tar.Z - the X color database viewer compiled on SGI

The SGI binaries are for Irix 4.0.1 and make use of the X11R4/Motif-1.1
shared libraries on the SGI.



Answer: The Solbourne OI toolkit (not Motif) also has a C++ binding.

-----------------------------------------------------------------------------
Subject: 105)+ The OpenWindows server hangs when I popup a menu with Button 3.
[Last modified: August 92]

Answer: This is an OpenWindows problem, but if you have Motif source you can
fix your own applications. From Steve Sistare of Thinking Machines Corp.:
"Change the 2 calls to XtGrabButton in RowColumn.c such that ButtonReleaseMask
| ButtonPressMask is passed for the event mask.  Currently, only
ButtonReleaseMask is passed.  Also, change the owner_event argument to FALSE.
" This has not been fixed in Motif as at 1.1.5.

-----------------------------------------------------------------------------
Subject: 120)*  How do I set the title of a top level window?
[Last modified: August 92]

Answer: Set XmNtitle (and optionally XmNtitleEncoding) for TopLevelShells.
Ypu can also set XmNiconName if you want its icon to show this title.  For
XmDialogShells, set the XmNdialogTitle of its immediate child, assuming it's a
BulletinBoard subclass.  These can also be set in resource files.


-----------------------------------------------------------------------------
Subject: 121)*  Can I use editres with Motif?
[Last modified: August 92]

Answer: It isn't built in to Motif (at 1.2.0), but you can do this in your
application

    extern void _XEditResCheckMessages();
    ...
    XtAddEventHandler(shell_widget, (EventMask)0, True,
                        _XEditResCheckMessages, NULL);

once for each shell widget that you want to react to the "click to select
client" protocol.  Then link your client with the R5 libXmu.

David Brooks, OSF


-----------------------------------------------------------------------------
Subject: 136)+ What order should the libraries be linked in?
[Last modified: August 92]

Answer: At link time, use the library order  -lXm -lXt -lX11. There are two
reasons for this (dbrooks@osf.org):

On most systems, the order matters because the linker won't re-scan a library
once it is done with it.  Thus any references to Xlib calls from Xm will
probably be unresolved.

The [other] problem is that there are two VendorShell widgets. A dummy is
provided in the Xt library, but a widget set will rely on its own being
referenced.  If you mention Xt first, the linker will choose the wrong one.

Motif code will wrongly assume the Motif VendorShell has been class-
initialized [and will probably crash].
 Xaw has a similar problem, but a softer landing; it only complains about
unregistered converters.


-----------------------------------------------------------------------------
Subject: 137)+ How do I make context sensitive help?  The Motif Style Guide
says that an application must initiate context-sensitive help by changing the
shape of the pointer to the question pointer. When the user moves the pointer
to the component help is wanted on and presses BSelect, any available context
sensitive help for the component must be presented, and the pointer reverts
from the question pointer.
[Last modified: August 92]

Answer: A widget that gives context sensitive help would place this help in
the XmNhelpCallback function. To trigger this function: (from Martin G C
Davies, mgcd@se.alcbel.be)

I use the following callback that is called when the "On Context" help
pulldown menu is selected. It does the arrow bit and calls the help callbacks
for the widget. It also zips up the widget tree looking for help if needs be.
I don't restrict the arrows motion so I can get help on dialog boxes. No
prizes for guessing what "popup_message" does.


static void ContextHelp(
    Widget              w ,
    Opaque              * tag ,
    XmAnyCallbackStruct * callback_struct
)
{
    static Cursor   context_cursor = NULL ;
    Widget          context_widget ;

    if ( context_cursor == NULL )
        context_cursor = XCreateFontCursor( display, XC_question_arrow ) ;

    context_widget = XmTrackingLocate( top_level_widget,
                                context_cursor, FALSE ) ;

    if ( context_widget != NULL ) /* otherwise its not a widget */
    {
        XmAnyCallbackStruct cb ;

        cb.reason = XmCR_HELP ;
        cb.event = callback_struct->event ;

        /*
         * If there's no help at this widget we'll track back
           up the hierarchy trying to find some.
         */

        do
        {
            if ( ( XtHasCallbacks( context_widget, XmNhelpCallback ) ==
                                                XtCallbackHasSome ) )
            {
                XtCallCallbacks( context_widget, XmNhelpCallback, & cb ) ;
                return ;
            }
            else
                context_widget = XtParent( context_widget ) ;
        } while ( context_widget != NULL ) ;
    }

    popup_message( "No context-sensitive help found\n\
for the selected object." ) ;
}



Dave Bonnett suggested, to use the following translations for XmText (and
XmTextField) widgets to get the same help with key strokes, and to provide an
accelerator label in the Context help menu entry.

MyApp*XmText*translations: #override\n\
                                <Key>F1:    Help()

MyApp*Help_menu*Contextual Help.acceleratorText:   F1

MyApp*defaultVirtualBindings:           osfBackSpace : <Key>Delete\n\
                                        osfRight : <Key>Right\n\
                                        osfLeft  : <Key>Left\n\
                                        osfUp    : <Key>Up\n\
                                        osfHelp  : <Key>F1\n\
                                        osfDown  : <Key>Down

-- 
+----------------------+---+
  Jan Newmarch, Information Science and Engineering,
  University of Canberra, PO Box 1, Belconnen, Act 2616
  Australia. Tel: (Aust) 6-2012422. Fax: (Aust) 6-2015041

  AARnet: jan@ise.canberra.edu.au
  ARPA:   jan%ise.canberra.edu.au@uunet.uu.net
  UUCP:   {uunet,ukc}!munnari!ise.canberra.edu.au!jan
  JANET:  jan%au.edu.canberra.ise@EAN-RELAY

+--------------------------+