Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!ncar!ico!attc!marbru
From: marbru@attc.UUCP (Martin Brunecky)
Newsgroups: comp.windows.x.motif
Subject: Re: Reparenting Widgets Dynamically ?
Message-ID: <917@attc.UUCP>
Date: 7 Dec 90 15:46:31 GMT
References: <POP.90Dec6112628@uci12.linus.mitre.org>
Reply-To: marbru@auto-trol.UUCP (Martin Brunecky)
Distribution: comp.windows.x.motif,comp.windows.x,mitre.motif
Organization: Auto-trol Technology, Denver
Lines: 41

In article <POP.90Dec6112628@uci12.linus.mitre.org> pop@linus.mitre.org (Paul O. Perry) writes:
>
>How is it possible to reparent a widget dynamically ?  
>
>I tryed XReparentWindow(XtDisplay(w), XtWindow(w), ...) but this seems
>like a sneaky thing to to a widget; in fact, a query to XtParent(w)
>showed that the widget did not consider its parent changed (of
>course). If I XtUnamanageChild(w) I don't get to XtManageChild(w) to a
>different parent.
>
>I'm trying to allow a user to move an XmPushButton from one XmForm to
>another.  I think that creating and destroying every time could be
>expensive, and that managing and unmanaging a widget per form that I
>have could also be expensive. What I think I will have to do is to

   I have the reparenting code - it's not THAT difficult. But the
   FIRST thing this code MUST do is unamange widget from the original
   parent; reparent; manage under the new parent. So there is no way
   to save this one, unless you are asking for a spectacular crash.
   Plus.
   XmForm is a constraint widget, so dealing with constraints becomes
   an issue. Where should the constraint values come from during the
   reparent operation ?
   The MIT folks opose the idea of reperenting, primarily because then
   you can't define resources through resource values, and whole bunch of
   other pittfals.

   To summ it, I don;t believe that your needs justify the reparenting.
   What you *can* consider, if you really want to *save*, is to reuse
   the entire form. Re-configuring which children are managed, what
   labels/callbacks are used etc. We do it for example for menus, keeping
   bunch of buttons for each cascade level, and managing only those we
   need at any given time.



-- 
=*= 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