marbru@auto-trol.UUCP (Martin Brunecky) (09/17/89)
I have written sevral Xtoolkit resource converters. Now I want to write one that uses (calls) an existing, standard Xtoolkit converter (such as XtRString to XtRCursor). However, ALL the converters are declared static (in addition, in DECwindows world, they are completely hidden in shareable image). The Intrinsic file Resource.c contains the code that looks-up the converter from the application code, but I can't use this approach either, since IntrinsicI.h is not supplied with DEXCwindows. Is there any reasonable way to get the converter pointer from the toolkit which I have overlooked ? Note, XtConverts needs a widget (to scan resource database), and in my converter I don't have one - and I don't want to pass one, since this would trash any caching if I understand it right. ############################################################################### Martin Brunecky, Auto-trol Technology Corporation, 12500 North Washington Street, Denver, CO-80241-2404 (303) 252-2499 ncar!ico!auto-trol!marbru -- ############################################################################### Martin Brunecky, Auto-trol Technology Corporation, 12500 North Washington Street, Denver, CO-80241-2404 (303) 252-2499 ncar!ico!auto-trol!marbru
swick@ATHENA.MIT.EDU (Ralph R. Swick) (09/19/89)
> Is there any reasonable way to get the converter pointer from the toolkit > which I have overlooked ? No, not really. And no specific work has been done to change this in the just-published revision document. > Note, XtConverts needs a widget (to scan resource database), and in my > converter I don't have one - and I don't want to pass one, since this > would trash any caching if I understand it right. Actually, XtConvert uses the widget principally to identify the application context and thereby lookup the currently-registered converter. You are correct that passing a widget id as a conversion argument would effectively disable caching for that conversion.
net@tub.UUCP (Oliver Laumann) (09/20/89)
In article <8909191143.AA08651@LYRE.MIT.EDU> swick@ATHENA.MIT.EDU (Ralph R. Swick) writes: > Actually, XtConvert uses the widget principally to identify the > application context and thereby lookup the currently-registered > converter. While we're at it... What I don't understand in this context is how one is supposed to use XtConvert() to convert the resource arguments to XtCreateWidget() and similar functions. It is obviously not possible, since in this case there is no widget ID that can be passed to XtConvert(). Note that it is not always possible to set the resources by means of XtSetValues() after the widget has been created; some resources *must* be specified at the point the widget is created. Yes, I know that the arguments to XtCreateWidget() et. al. are converted automatically. We have an application that requires that resources are converted explicitly (e.g. by means of XtConvert()). Regards, -- Oliver Laumann net@TUB.BITNET net@tub.UUCP
swick@ATHENA.MIT.EDU (Ralph R. Swick) (09/20/89)
> What I don't understand in this context is how one > is supposed to use XtConvert() to convert the resource arguments to > XtCreateWidget() and similar functions. It is obviously not possible, > since in this case there is no widget ID that can be passed to XtConvert(). The best you can do is specify an alternate widget that you believe will provide the same conversion arguments to the type converter. The ones that matter as far as Core resources are concerned are screen and colormap. The first shouldn't be a problem and your application probably has a pretty good idea about what widgets are sharing specific colormaps.