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 Asente 
   Organization: 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