cpkt@marlin.jcu.edu.au (Katya Ta) (04/10/91)
Hi, Does anyone know how to get a widget from its name? I have a reference to a function XmuCvtStringToWidget, but no details on how to use it. Thanks in advance Katya (ta_k@maths.su.oz.au)
achan@sparkle.nec.com (Amy Chan) (04/10/91)
In article <1991Apr10.003309.10438@marlin.jcu.edu.au> cpkt@marlin.jcu.edu.au (Katya Ta) writes: >Hi, > Does anyone know how to get a widget from its name? I have a reference >to a function XmuCvtStringToWidget, but no details on how to use it. > > You can also use the function XtNameToWidget to get the widget ID for the specified widget instance name. Amy Chan NEC America, Inc. achan@tdd.sj.nec.com
gnb@bby.oz.au (Gregory N. Bond) (04/11/91)
>>>>> On 10 Apr 91 16:18:39 GMT, achan@sparkle.nec.com (Amy Chan) said:
Amy> You can also use the function XtNameToWidget to get the widget ID
Amy> for the specified widget instance name.
A gotcha with this: It only succeeds on children that are real,
fairdinkum managed children of a composite widget - I assume because
it looks at the composite.num_children and composite.children fields.
Some widgets have "hidden" children that are XtCreate'd but not
managed (composite dialog boxes, sources or sinks for text widgets
etc) where the pointer to the child widget is stored somewhere in the
parent widget instance record. XtNameToWidget cannot find these.
A consequence of this is that Wcl (which uses XtNameToWidget
internally) cannot use the WcSetValueCB callback to set their
resources.
(I noticed this on the AtPlotter widget where the axes are hidden
widgets. I have a fix for this - make them managed children!)
Greg.
--
Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia
Internet: gnb@melba.bby.oz.au non-MX: gnb%melba.bby.oz@uunet.uu.net
Uucp: {uunet,pyramid,ubc-cs,ukc,mcvax,prlb2,nttlab...}!munnari!melba.bby.oz!gnbmarbru@auto-trol.com (Martin Brunecky) (04/16/91)
In article <GNB.91Apr11172247@leo.bby.oz.au> gnb@bby.oz.au (Gregory N. Bond) writes: >>>>>> On 10 Apr 91 16:18:39 GMT, achan@sparkle.nec.com (Amy Chan) said: > >A gotcha with this: It only succeeds on children that are real, >fairdinkum managed children of a composite widget - I assume because >it looks at the composite.num_children and composite.children fields. >Some widgets have "hidden" children that are XtCreate'd but not >managed (composite dialog boxes, sources or sinks for text widgets >etc) where the pointer to the child widget is stored somewhere in the >parent widget instance record. XtNameToWidget cannot find these. > Any widget created by XtCreate... is added to either composite.children or the popup list. Does not matter if it's "fairdinkum managed" or unmanaged. The only way to create an "orphan" widget is to use a non-composite parent, which (IMHO) is not a good practice, (in fact, I'd prefere to make it illegal). Athena Text source/sink are aparent examples of the later; IMHO this widget should be a composite. Or it should create source/sink as children of the Text's parent (which opens yet another can of worms). Composite dialog boxes are (normally) subclass of Composite, so there should be no problem ... -- Martin -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404