nazgul@alphalpha.com (Kee Hinckley) (09/15/90)
We have a situation in which we need context sensitive popups.
The area in which this occurs will have a dynamically changing
set of widgets, and the C++ wrappers for those widgets automatically
will indicate that they need a particular popup. So far so good.
We ran into some interesting anomalies.
Let's say the set up is a Form with a series of widgets inside it.
I don't want to create a special popup for each widget, many of the
widgets have the same popup. So I want to create one popup of
each type (or perhaps even less, and just rearrange the contents)
and then manage it whenever appropriate.
Who do you use as the parent of the popup?
1) If you use the Form, but don't add an event handler for it (and just
put event handlers in each of the individual widgets), the popup will
never show up. Instead the cursor will change to the menu arrow for
a little while, and then shift back - that's all.
2) If you use the Form and *do* put an event handler on it, the event
will get delivered alright - but to the form, not to the individual
widgets - so you have no (easy) way of telling who was supposed to get it.
3) A probably related problem. Suppose I want a popup on the Form that
takes care of the default cases, and then individual ones on certain
labels. It doesn't appear to be possible. If you put an event handler
on the Form, that's the only one that will be executed, you can't have
subsidiary popups on it's children.
The work around (for all but #3) is to create the popup off of a
child widget that has no children (that you are interested in) and
then add event handlers to the widgets you care about. This was
somewhat more complicated for us, because any of the widgets may
be deleted by the user ("I thought you were writing a mail program,"
you say. "Well, yes, but... you'll see."). Our eventually solution
was to create a cheap widget (is separator the cheapest, or is there
a better one?) and not manage it. We create the popup off of *that*
widget, and then put event handlers on the managed widgets we care
about.
All of this would appear to apply to both Motif 1.0 and 1.1. It's
not clear to me whether there is a bug here, or this is some side
effect of how events are handled in Xt, or what, but I thought it
was worth bringing up in case anyone else needs to deal with it.
-kee