nazgul@alphalpha.com (Kee Hinckley) (08/15/90)
> I have a pushbutton within a form within a dialog shell. When I push the > button, not only does it call the callback that I have added, but it also > exits the whole dialog! I presume it unmanages it but I don't know. The You want to set XmNautoUnmanage to False in the dialog. Alphalpha Software, Inc. | motif-request@alphalpha.com nazgul@alphalpha.com |----------------------------------- 617/646-7703 (voice/fax) | Proline BBS: 617/641-3722 I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. -------
heiney@wsl.dec.com (Bob Heiney) (08/16/90)
In article <9008150552.AA01009@ucisae.isae.cancol.oz>, jan@ucisae.isae.cancol.oz.au (Jan Newmarch) writes: |> |> I have a pushbutton within a form within a dialog shell. When I push the |> button, not only does it call the callback that I have added, but it also |> exits the whole dialog! I presume it unmanages it but I don't know. The |> bulletin board doco says that it defines Btn1Down as Arm() and Btn1Up |> as Activate() but that doesn't help me much. I want the dialog to stick |> around until I tell it to go. |> but that leaves these questions: a) Am I doing this the right way; b) Who |> is adding these extra callbacks (if that's what is happening), and what |> do they do; and c) Why the *?!!?* can't I find it in the Motif doco? Try looking at the BulletinBoard resource XmNautoUnmanage. Page 1-187 of the hardcover OSF/MOTIF Programmer's reference says: XmNautoUnmanage Controls whether or not BulletinBoard is automatically unmanaged after a button is activated. If True, BulletinBoard adds a callback to button children ... that unmanages the BulletinBoard when a button is activated; and, the unmap callbacks are called if the parent of the BulletinBoard is a DialogShell. If False, the BulletinBoard is not automatically unmanaged. The default value is True. Hope this answers your question. :-) Bob Heiney Graphics Consultant heiney@dec.com
cuweiss.US2.oramail@us.oracle.com ("Connie Weiss ", note the U =>) (08/16/90)
In-Reply-To: DVLSEQ:motif-request@alphalpha.com's message of 08-15-90 15:51 I had the same problem, with a pushbutton in a bulletin board dialog. My workaround was to put the pushbutton in a row column widget (even though it was just one button). It's a mystery to my as to why it behaves this way, I'm just hoping it's fixed in 1.1. Connie Weiss (cuweiss@oracle.com) ---- Included Message ---- Received: 08-15-90 09:41 Sent: 08-15-90 15:51 From: DVLSEQ:motif-request@alphalpha.com To: motif%alphalpha.com@munnari.OZ.AU Subject: Pushbutton callback problem Reply-To: DVLSEQ:motif-request@alphalpha.com Resent-From: nazgul@alphalpha.com (Kee Hinckley) Resent-Message-Id: <9008151530.AA25102@alphalpha.com> X-Mailer: ELM [version 2.2 PL0] Resent-To: motif-tmp@alphalpha.com Resent-Date: Wed, 15 Aug 90 11:30:25 EDT I have a pushbutton within a form within a dialog shell. When I push the button, not only does it call the callback that I have added, but it also exits the whole dialog! I presume it unmanages it but I don't know. The bulletin board doco says that it defines Btn1Down as Arm() and Btn1Up as Activate() but that doesn't help me much. I want the dialog to stick around until I tell it to go. I have discovered the following workaround: use XtRemoveAllCallbacks on XmNarmCallback and XmNdisarmCallback before adding my own callbacks, but that leaves these questions: a) Am I doing this the right way; b) Who is adding these extra callbacks (if that's what is happening), and what do they do; and c) Why the *?!!?* can't I find it in the Motif doco? +----------------------+---+ | Jan Newmarch |:-)| ACSnet: jan@ucisae.isae.cancol.oz.au | Info. Sciences & Eng.|___| ARPA: jan%ucisae.isae.cancol.oz.au@uunet.uu.net | Univ Canberra | UUCP: {uunet,ukc}!munnari!ucisae.isaecancol.oz.au!jan | P.O. Box 1 | CSNET: jan%uciase.isae.cancol.oz@australia | Belconnen A.C.T. 2616 | JANET: jan%au.oz.cancol.isae.ucisae@EAN-RELAY | AUSTRALIA | +--------------------------+
watson@dev1f.mdcbbs.com (08/18/90)
In article <9008151804.AA10891@dvlseq.us.oracle.com>, cuweiss.US2.oramail@us.oracle.com ("Connie Weiss ", note the U =>) writes: > In-Reply-To: DVLSEQ:motif-request@alphalpha.com's message of 08-15-90 15:51 > > > I had the same problem, with a pushbutton in a > bulletin board dialog. My workaround was to put > the pushbutton in a row column widget (even > though it was just one button). It's a mystery > to my as to why it behaves this way, I'm just > hoping it's fixed in 1.1. > > Connie Weiss > (cuweiss@oracle.com) > > This problems refers to activation of push button children of bulletin board or form dialogs causing the dialog to be unmanaged. As mentioned in other replies, setting the XmNautoUnmanage resource to false for the bulletin board or form dialog parent will stop this behavior. XmNautoUnmanage is a resource of XmBulletinBoard and XmForm, but NOT a resource of XmRowColumn, so making your push button the child of a row column circumvents the auto unmanage behavior of the bulletin board parent, as it should. Let's hope this isn't "fixed in 1.1", since it seems to be behaving as expected. Catie Watson McDonnell Douglas Manufacturing & Engineering Cypress, California (watson@dev1.mdcbbs.com)