Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!bloom-beacon!dont-send-mail-to-path-lines
From: converse@expo.lcs.mit.EDU (Donna Converse)
Newsgroups: comp.windows.x
Subject: Re: Restoring a widget's default translations
Message-ID: <9104221603.AA16556@excess.lcs.mit.edu>
Date: 22 Apr 91 16:03:25 GMT
References: <1991Apr21.231152.26500@bellcore.bellcore.com>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: X Consortium, MIT Laboratory for Computer Science
Lines: 52


> In article <9104191458.AA10004@excess.lcs.mit.edu>, converse@expo.lcs.mit.EDU (Donna Converse) writes:
> > 
> > Yes, you can do XtGetValues on the translations resource of a widget,
> > save the returned value, and later use XtSetValues to restore those 
> > translations on that widget.   These translations might include 
> > translations specified by the user or by the application writer.

Theory:

> Is this supported by Xt?  When you do an XtGetValues on a widgets
> translations, you get a pointer to private internal widget data.
> Is pointed to data guaranteed to be valid beyond the next call to
> an Xt function?

The R4 Xt specification doesn't speak directly to the general question 
of the lifetime of the data referenced by pointers passed to the client
with XtGetValues.  In the general case, the most strict assumption 
(without referring to the implementation) is that the data is available 
at least until the next call to an Xt function, and Xt memory allocation 
routines can be used to copy the data.  

But there are no interfaces to copy or to free XtTranslations, so in
the case of translations it is reasonable to assume that you are being
passed a pointer to uncopied data whose lifetime is managed by Xt.  
Towards the end of section 10.3:

	The merge operation produces a new translation resource value;
	if the original table was shared by other widgets, they are
	unaffected.

This implies that the translation resource value returned by XtGetValues
on a widget's translations is unaffected by a merge operation on the 
translations of any widget, even the same widget.


Practice:

> Both xmh and an earlier release of xrn do this (XtGetValues on
> XtNtranslations, save the result, XtSetValues with it later).
> As a result they both occasionally core dump.  I was never sure
> if this was due to a bug in Xt, or if it was because this
> is unsupported behavior.

Bug in Xt.

> So, is it OK to do this but it just doesn't work because of an Xt bug?

Yes.


Donna Converse