Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!agate!garnet.berkeley.edu!csvsj
From: csvsj@garnet.berkeley.edu (Steve Jacobson)
Newsgroups: comp.windows.x
Subject: Re: widget name
Keywords: how to access
Message-ID: <25353@agate.BERKELEY.EDU>
Date: 8 Jun 89 17:19:23 GMT
References: <1937@aucs.UUCP>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: csvsj@garnet.berkeley.edu (Steve Jacobson)
Organization: University of California, Berkeley
Lines: 47

In article <1937@aucs.UUCP> ifocs9d@aucs.UUCP (Rick Giles) writes:
>
>How do I get the name which was used in creating an HP widget later on in
>the program? I'm guessing that it's possible using XtGetValues, but haven't
>been able to discover the correct name/address pair for an argument list.
>Any help will be appreciated.
>
>(A more general question is, How should I associate extra data with a
>widget, and later access it?).
>
>Rick Giles
>
>Bitnet:   FRGILES@Acadia                        | Procrastinators
>Internet: FRGILES%Acadia.BITNET@CUNYVM.CUNY.EDU | finish
>UUCP:     uunet!dalcs!aucs!ifocs9d              | first.

Here's one way to do it:

You can put data or a pointer to data in the closure member of the
XtCallbackRec. Make a simple noop() function that just returns and
use that for the callback member. Use XtAddCallback to add it to one
of the widget's callback lists. The destroy callback list is a good
one to use.

You can then use XtGetValues to retrieve the Callback list to examine the
closure value. To change the closure value, you have to first use
XtRemoveCallback to remove the structure with the existing closure value,
and then use XtAddCallback to add it back with the new closure value.

You have to be a little careful - most widgets don't have a destroy
callback, but you can't always assume that the callback you added will 
always be the only one. For example, the HP menu managing widget adds a
destroy callback to its parent widget. So you either have to "know" where
your callback structure is in the list, or you need to check the callback
member, looking for the pointer to your noop() function.

This stuff only works with the R3 intrinsics (Xt). The callbacks were screwed
up in R2; it was possible to use the callbacks in this manner, but you
had to do some really ugly things (the method outlined above isn't
so pretty, but at least it doesn't violate the toolkit's object data
hiding practices).

All this stuff would be unneccesary if there was a "client data" resource
in the Core widget. Then simple and sensible XtGetValues and XtSetValues
calls would do the trick.

I asked about this in a posting and mailing, but got no response.