ltlovett@eos.ncsu.edu (LANCE TIMOTHY LOVETTE) (11/10/90)
I created a menu bar with XmCreateMenuBar. On the bar I put a cascade button to drop a pull down menu. My problem is I want to have an 'about' PushButtonWidget on the bar so that when pressed it pops up a dialog box. The program compiles and will run like I want, no problems, except for when it first runs I get the message: X Toolkit Warning: Name: menu_bar Class: XmRowColumn Attempt to add wrong type child to a homogeneous RowColumn widget I tried setting the XmNentryClass to NULL and the XmNisHomogeneous to False but that accomplished nothing. Also how can I position the widgets on the menu bar like this: _______________________________________________________________ Options File Help About _______________________________________________________________ with the 'about' to the far right. I tried setting the XmNx and XmNy positions but once again nothing was accomplished. Thanks a lot, Lance Lovette NCSU CSC
slh@wolf.cs.washington.edu (Scott Heyano) (11/11/90)
>From: ltlovett@eos.ncsu.edu (LANCE TIMOTHY LOVETTE) | I created a menu bar with XmCreateMenuBar. On the bar I put a cascade | button to drop a pull down menu. My problem is I want to have an 'about' | PushButtonWidget on the bar so that when pressed it pops up a dialog box. | The program compiles and will run like I want, no problems, except for when | it first runs I get the message: | | X Toolkit Warning: | Name: menu_bar | Class: XmRowColumn | Attempt to add wrong type child to a homogeneous RowColumn widget | | I tried setting the XmNentryClass to NULL and the XmNisHomogeneous to | False but that accomplished nothing. Also how can I position the widgets You are not allowed to change these values on a RowColumn of type XmMENUBAR. | on the menu bar like this: | | _______________________________________________________________ | Options File Help About | _______________________________________________________________ | with the 'about' to the far right. I tried setting the XmNx and XmNy | positions but once again nothing was accomplished. | Setting the XmNmenuHelpWidget resource of the menubar widget to the about-button widget will put it on the right, not sure what all else this does though. | Thanks a lot, | | Lance Lovette | NCSU CSC |
toml@marvin.Solbourne.COM (Tom LaStrange) (11/12/90)
> I tried setting the XmNentryClass to NULL and the XmNisHomogeneous to > False but that accomplished nothing. Also how can I position the widgets > on the menu bar like this: > > _______________________________________________________________ > Options File Help About > _______________________________________________________________ > with the 'about' to the far right. I tried setting the XmNx and XmNy > positions but once again nothing was accomplished. > Be aware that once you arrange your menu bar buttons like this, you will not be able to certify your application as "Motif compliant". The OSF documents state that if a Help button is present, it must be in the far right of the menu bar. I don't have the OSF stuff in front of me right now so I can't quote it to you. -- Tom L. toml@Solbourne.COM
dex@hpcvlx.cv.hp.com (Dex Smith) (11/12/90)
To follow the OSF/Motif Style Guide, the menu should be arranged like
this:
--------------------------------------------
File Options Help
--------------------------------------------
The "About" command belongs within the Help menu.
This design also avoids the problem of putting a different kind of
button in the menu bar, which often creates usablilty problems.
Dex Smith
Hewlett-Packard Company
dex@hpcvlx.hp.comdarmstro@excalibur.tn.cornell.EDU (Doug Armstrong) (11/12/90)
In 1461 Lance Lovette mentions a problem with MenuBar children. Perhaps the RTFM theory has kept others from responding to his problem, but I spent half a day tracking down the same problem when I was first writing a real menu bar. Its a hard line to find. My ancient (1989) Motif Reference Manual has the following under XmRowColumn: XmNentryClass: "When XmNrowColumnType is set to XmMENU_BAR, then the value of XmNentry is **forced** to xmCascadeButtonWidgetClass." (emphasis mine) All is not lost, however, since (to my surprise) Cascade Buttons support a activate callback list and do not require a submenu. Since I don't need the arm and disarm callbacks that PushButtons support, I've never missed them on my menu bars. Doug Armstrong darmstro@theory.tn.cornell.edu CNSF / Technical Integration Group
kumorek@apollo.HP.COM (James Kumorek) (11/13/90)
In article <1990Nov9.223934@eos.ncsu.edu>, ltlovett@eos.ncsu.edu (LANCE TIMOTHY LOVETTE) writes: |> |> I created a menu bar with XmCreateMenuBar. On the bar I put a cascade |> button to drop a pull down menu. My problem is I want to have an 'about' |> PushButtonWidget on the bar so that when pressed it pops up a dialog box. |> The program compiles and will run like I want, no problems, except for when |> it first runs I get the message: |> |> X Toolkit Warning: |> Name: menu_bar |> Class: XmRowColumn |> Attempt to add wrong type child to a homogeneous RowColumn widget |> Menu bars require that all the children of the menu bar be the same 'type' of widget (or gadget). To get around this problem, use a cascade button or gadget for the button that will invoke the dialog box; just don't set the subMenuId resource. It should then act just like a push button. Jim Kumorek Apollo Computer, Inc. - A subsidiary of Hewlett Packard kumorek@apollo.hp.com
jan@ECHO.CANBERRA.EDU.AU (Jan Newmarch) (11/13/90)
> Menu bars require that all the children of the menu bar be the same 'type' > of widget (or gadget). To get around this problem, use a cascade button or > gadget for the button that will invoke the dialog box; just don't set the > subMenuId resource. It should then act just like a push button. But then the Style Guide will get you (just like it got me some time ago). You can't have commands in the menu bar, and that is "unlikely to change". "If it is important enough to require its own button, then it should be a separate button elsewhere, not in the menu bar" (Motif Style Guru). Use a pulldown from the menu bar and hang the dialog off an item in it, or put it somewhere else. +----------------------+---+ Jan Newmarch, Information Science and Engineering, University of Canberra, PO Box 1, Belconnen, Act 2616 Australia. Tel: (Aust) 6-2522422. Fax: (Aust) 6-2522999 ACSnet: jan@ise.canberra.edu.au ARPA: jan%ise.canberra.edu.au@uunet.uu.net UUCP: {uunet,ukc}!munnari!ise.canberra.edu.au!jan JANET: jan%au.edu.canberra.ise@EAN-RELAY +--------------------------+
argv@turnpike.Eng.Sun.COM (Dan Heller) (11/14/90)
In article <4df75675.20b6d@apollo.HP.COM> kumorek@apollo.HP.COM (James Kumorek) writes: > Menu bars require that all the children of the menu bar be the same 'type' > of widget (or gadget). To get around this problem, use a cascade button or > gadget for the button that will invoke the dialog box; just don't set the > subMenuId resource. It should then act just like a push button. Please don't do this -- this was not the intent of the GUI's use of menubars. You must keep in mind that the intent of a GUI is to maintain consistency across all applications that use that GUI. If you start doing things like this, users who are using stictly Motif-based applications are going to get confused when they get to yours because it's doing something differently from the others. As one poster pointed out some weeks ago, a common thing to do is to "drag thru the menubar" to examine all the submenus within to get a preview of what sort of functions are available. -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.
lcp@ibism.UUCP (Larry Poleshuck) (11/16/90)
In article <2659@exodus.Eng.Sun.COM>, argv@turnpike.Eng.Sun.COM (Dan Heller) writes: > In article <4df75675.20b6d@apollo.HP.COM> kumorek@apollo.HP.COM (James Kumorek) writes: > > Menu bars require that all the children of the menu bar be the same 'type' > > of widget (or gadget). To get around this problem, use a cascade button or > > gadget for the button that will invoke the dialog box; just don't set the > > subMenuId resource. It should then act just like a push button. > > Please don't do this -- this was not the intent of the GUI's use of > menubars. You must keep in mind that the intent of a GUI is to We have tried this technique (i.e., using a cascade button with no subMenuId and with an activate callback, even though it is not consistant with Motif style. To get even with me Motif would not let me step into the code executed by the activate callback. When I set a breakpoint in the callback routine and hit the cascade button, my interface freezes. No window will accept input from keyboard or mouse. The application is locked in my debugger, but the debugger will not accept input. I am using TeleUSE (Motif 1.0.3) on SunOS and the problem occurs when the callback is a D-routine being debugged with the TeleUSE D debugger and when the callback is a c routine being debugged with dbxtool. Has anyone else seen this? -- Larry Poleshuck Citibank 111 Wall Street New York, NY 10043 Phone: 212-657-7709 Fax: 212-657-0068 E-Mail: uunet!ibism!lcp
roger@zuken.co.jp (Roger Meunier) (12/07/90)
In article <12085@ibism.uucp> lcp@ibism.UUCP (Larry Poleshuck) writes: > We have tried this technique (i.e., using a cascade button with no subMenuId > and with an activate callback, even though it is not consistant with Motif > style. To get even with me Motif would not let me step into the code executed > by the activate callback. When I set a breakpoint in the callback routine and > hit the cascade button, my interface freezes. > > Has anyone else seen this? I haven't seen any response to this one yet, so let me give it a whirl. I got bit by this one, too. It's not because you violated any style rules, but because Motif grabs both the pointer and the keyboard while a CascadeButton is active, and doesn't ungrab until after any callback is complete. I got around this by calling XUngrabPointer() and XUngrabKeyboard() (don't forget to XFlush()!) on entry to the callback(s) and then setting a breakpoint on a subsequent statement. Not very elegant, but it gets the job done. Hope this helps. -- Roger Meunier @ Zuken, Inc. Yokohama, Japan (roger@zuken.co.jp)