Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!software.ORG!begeddov From: begeddov@software.ORG (Gabriel Beged-Dov) Newsgroups: comp.windows.x Subject: Clarification of "passing widget args to subwidgets" Message-ID: <8809182215.AA23604@ATHENA.MIT.EDU> Date: 18 Sep 88 20:38:25 GMT References: <785@bacchus.dec.com> Sender: daemon@bloom-beacon.MIT.EDU Organization: The Internet Lines: 64 Date: 17 Sep 88 00:56:48 GMT From: Paul AsenteOrganization: DEC Western Software Lab References: <5681@pasteur.Berkeley.EDU> Sender: xpert-request@athena.mit.edu In article <5681@pasteur.Berkeley.EDU> dheller@cory.Berkeley.EDU (Dan Heller) writes: >The question at hand is: how do you call XtCreate[..]Widget() and >pass XtN... parameters that are intended for "sub"-widgets within >the widget, not intended for the widget itself that you're creating. One sentence answer: use Xt{Get,Set}Subresources in the parent widget's initialize_hook, set_values_hook, and get_values_hook procedures. How would you handle chained sub-widget resources (i.e. ones that are defined in a superclass of the sub-widget)? Also, how would the sub-widget set_value methods get invoked ? Many of the HP widgets seem to deal with similar issues to the ones Dan Heller is raising (see XwScrollBarWidget, XwScrolledWindowWidget, XwTitleBarWidget). There, the parent usually defines a set of "shadow" resources that are the external interface (both for the application and the resource DB) for accessing the state of the sub-widgets (without having to know thier names). SetValues of these resources are often simply passed thru, by the parent, to the "real" resources in the sub-widget. In other cases the parent has some private state or constraints associated with the value of the "shadow" resource. GetValues can be a little trickier. There seem to be 3 approaches that a parent can take in order to keep the shadow resource in synch with the child resource. "Write-Thru" is the default one where the parent assumes that whatever value was last written to the child is correct. "Immediate Write-Back" (which is what the HP Scrollbar uses) gets the child resource values immediately after setting them thereby ensuring synch at that point. "Lazy Write-Back" is something a really paranoid parent might do by having a get_values_hook procedure that would check if any shadow resources were being requested and then get them from the child. Dan also mentions passing thru callbacks to the sub-widget which has a different set of problems. A parent cannot naively pass-thru a callback resource to a child. The main reason is that callback lists have two representations (internal and external). XtCreate (or XtAddCallback) expects Callback lists to be in external format and then compiles them into internal format. If the child is created and passed the shadow callback list, the list will already be in internal format (as a result of the XtCreate or XtAddCallBack done to the parent). The intrinsics will then try to recompile it for the child (not what you want). One way the parent can handle this is to have a callbackProc that it adds to the sub-widget callback list instead of passing thru the shadow list. When this callbackProc is called it should invoke the entries on the shadow callback list managed by the parent. Gabe Beged-Dov csnet: begeddov@software.org Software Productivity Consortium arpanet: begeddov%software.org@relay.cs.net