montnaro@spyder.crd.ge.com (Skip Montanaro) (04/19/91)
Is there a way to restore a widget's default translations? I saw nothing obvious in the R4 Intrinsics manual. I could maybe hack it by instancing another widget of the same type and grabbing its translations resource, but that becomes sticky with extremely modal widgets like Motif's RowColumn widget, which has all sorts of different behavior, depending upon the setting of various resources. Thanks, -- Skip (montanaro@crdgw1.ge.com)
converse@expo.lcs.mit.EDU (Donna Converse) (04/19/91)
> Is there a way to restore a widget's default translations? No, I don't see how an application can force the installation of the widget class's default translations onto an instance of that class. 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. If you have a specific set of translations to restore on multiple widgets, compile them once with XtParseTranslations and use the returned value with XtSetValues on multiple widget instances, multiple times, to restore that set of translations. In fact, this is the best way to rotate through modal translations. Some applications might be calling XtParseTranslations and XtAugment or OverrideTranslations within a callback or an action procedure. These applications may show memory usage growth without bound as they cycle through changes in translations. Calling XtParseTranslations more than once on the same string is wasteful, and successively calling XtOverrideTranslations or XtAugmentTranslations to merge translations on mode changes can be exceedingly wasteful. Essentially the same points hold for accelerators. > I could maybe hack it by instancing > another widget of the same type and grabbing its translations resource Hmm, read the specification; I'm not convinced that this is supported. Donna Converse
aw@jello.bae.bellcore.com (Andrew Wason) (04/22/91)
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. 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? 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. So, is it OK to do this but it just doesn't work because of an Xt bug? Andrew _______________________________________________________________________________ Andrew Wason Bell Communications Research aw@bae.bellcore.com Piscataway, NJ bellcore!bae!aw
converse@expo.lcs.mit.EDU (Donna Converse) (04/22/91)
> 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
marbru@auto-trol.com (Martin Brunecky) (04/24/91)
In article <1991Apr21.231152.26500@bellcore.bellcore.com> aw@bae.bellcore.com writes: >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. > >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? > Just wondering... If the translations I am getting (XtGetValue) went through the resource conversion mechanism, the parsed translations are cached, so the (opaque) handle I get remains valid forever. However, if the translations I am getting is something set by the application or some other widget, I am not quite so sure. On the other hand, all the (opaque) translation handles are "created" by XtParseTranslations (XtOverrideTranslations....). Do those call "cache" the translation structure(s) so that the (opaque) translations handle is always VALID ? (I don't see any XtFreeTranslations call -). -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky marbru%auto-trol@sunpeaks.central.sun.com (303) 252-2499 (better avoid: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404