HDTenEightyP/NetNews huggingface dataset:
From: richm@netcom.com (Richard Mauri)
Subject: Re: Need subclassing help!?
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Fri, 20 Nov 1992 15:21:29 GMT

In article <4312@cvbnetPrime.COM> dhukill@esprit.prime.com (Dave Hukill x4056 5-1) writes:
>I'm having a problem with a widget I've subclassed under motif. I get the
>following error:
>
>Warning: 
>    Name: menubar
>    Class: XmRowColumn
>    Attempt to add wrong type child to a homogeneous RowColumn widget
>
>The code looks like this:
>
>      shell = XtAppInitialize(&appContext,
>			      "myWidgetApp",
>			      NULL,
>			      0,
>			      &argc,
>			      argv,
>			      NULL,
>			      NULL,
>			      0);
>
>      menuBar = XmCreateMenuBar(shell,
>				"menubar",
>				NULL,
>				0);
>      XtManageChild(menuBar);
>
>      menuPulldown = XmCreatePulldownMenu(menuBar,
>					  "menuPulldown",
>					  NULL,
>					  0);
>
>      menuItem = XtVaCreateManagedWidget("menu item",
>					 xmPushButtonWidgetClass,
>					 menuPulldown,
>					 NULL);
>      XtAddCallback(menuItem, XmNactivateCallback, menuItemCallback, NULL);
>
>      menuButton = XtVaCreateManagedWidget("menu button",
>					   myMenuButtonWidgetClass,
>					   menuBar,
>					   XmNsubMenuId, menuPulldown,
>					   NULL);
>
>Obviously, my class is 'muMenuButtonWidgetClass'. The strange thing is that
>the widget works properly. I'm running Quest Motif version 1.1.4 on Sun SPARC.
>I've checked and double-checked the class initializations in the class record,
>and they appear to be fine. I've successfully sub-classed this widget under
>OLIT, but other than the 'core' class, they're quite different.
>
>Any input on this problem would be greatly appreciated!
>
>advTHANKSance - 
>Dave Hukill <dhukill@esprit.prime.com>

Here are some observations:
1. Your RowColumn does not explicitly set the XmNisHomogeneous
resource, since you use the menubar convenience function, you
let it set the resource to True for you. Try setting it to
False after creating the menubar.
2. Normally you add cascade buttons as children of menubar's
but you add a pulldown menu and your myMenuButtonWidgetClass
which are not nomogeneous.
3. Have you stepped through in synchronous mode to find out
which is the offending call. Sounds like the problem isn't
in your myMenuButtonWidgetClass but it is different than
the first rowcolumn child and as such appears to be you
widget class. It is the row column that is screaming.
4. Try using homogeneous children of the rowcolumn
or setting the resource to False.
Rich Mauri
-- 
Richard Mauri               // Not ready to face the winter.
SW Eng / X hack             // Pray for wind.
Trimble Navigation Ltd.     // Pay the bills.
richm@netcom.com	    // Hope nothing breaks
From: smerrill@aristotle.ils.nwu.edu (Shannon Merrill)
Newsgroups: comp.windows.x.motif
Subject: FAQ Request
Date: 17 Nov 92 15:34:12 GMT
Article-I.D.: ils.1992Nov17.153412.27336
Organization: The Institute for the Learning Sciences
X-Useragent: Nuntius v1.1

Could someone please email me a complete copy of this or last month's
FAQ?  My address is smerrill@ils.nwu.edu

Thanks!
Newsgroups: comp.windows.x.motif
From: jarnold@spot.wrc.xerox.com (jeff arnold esc1-318)
Subject: Clean up ... 
Organization: Xerox
Date: Thu, 19 Nov 1992 23:50:47 GMT


Hi,
  I've got a motif program which consists of 2 application shells
and a few top level shells.  A callback function is invoked once
the "Quit" pushbutton is selected.  Now, what's the most elegant
way to terminate this program?

I could ...

1) exit(0); 

2) XtDestroyWidget(applicationShell1);

I tried 2 but it printed out: "Error: Cannot perform malloc".  What
am I doing wrong? Is exit(0) acceptable? Or is there another way
of doing it?

Thanks,

Henry
Newsgroups: comp.windows.x.motif
From: timmerma@sun006.research.ptt.nl (Wim Timmerman)
Subject: Applying fixes to X11R5 for building Motif 1.2
Keywords: patches, Motif 1.2, X11R5
Organization: PTT Research, Groningen
Date: Mon, 16 Nov 1992 15:27:20 GMT



I am trying to install the OSF Motif 1.2 source code on my system. According to the manuals, I first have to apply fixes to the X11R5 libraries. Therefore I need a patch program.

I have 2 questions:

   1) Is it strictly necessary to apply the fixes to the X11R5 libraries?
   2) If so, where can I get the appropiate patch program ?

It would be of great help if anyone could answer these questions.


	Greetings,

	Wim Timmerman
	E-mail: <timmerma@sun006.research.ptt.nl>

 
Newsgroups: comp.windows.x.motif
From: kshomper@harp.cis.ohio-state.edu (keith shomper)
Subject: How do you keep multiple dialogs managed at the same time?
Organization: The Ohio State University Dept. of Computer and Info. Science
Distribution: usa
Date: Fri, 20 Nov 1992 15:18:01 GMT

     How do I keep a SelectionBoxDialog managed while managing an ErrorDialog?

     Can anyone point me to an example answering the above question?  I create
a SelectionBoxDialog with XmCreateSelectionDialog and an ErrorDialog with
XmCreateErrorDialog.  My intent is to popup the ErrorDialog in the
noMatchCallback, and leave the SelectionBoxDialog managed until the user
responds to the error, at which point he/she would try again.  However, whenever
I manage the ErrorDialog with XtManageChild, the SelectionBoxDialog is 
unmanaged (somehow).


     My resources for the SelectionBoxDialog and the ErrorDialog set 
autoUnmanage to False, so I'm sure I'm not getting zapped by this (see FAQ item
85).  The dialogStyle for each is set to XmDIALOG_PRIMARY_APPLICATION_MODAL.

     Heller points out that shell widgets may have only one managed child.
Is my problem related to this?  I've tried createing the dialogs with different
widget parents and with the same widget parent.  The results are the same.  Any
info on this problem is appreciated.

Keith
From: deveau@oceanroutes.ns.ca ("Terry J. Deveau")
Newsgroups: comp.windows.x.motif
Subject: Re: POSITIONING of dialog boxes. How do I do that ???
Date: 16 Nov 92 15:26:57 GMT
Distribution: inet
Organization: Oceanroutes Canada Inc.

Andreas Manessinger <man@magwien.gv.at> writes:
> 
> What I want (ideally) is, that new boxes are always created in the
> proximity of the mouse pointer.
> 
> What I tried is:
> 
>         Creating the widgets as children of the box that contains the 
>         initiating push button and setting `XmNdefaultPosition' to
>         `true'. This works quite well, the widgets appear in a
>         position centered to their parent, but I look for a solution
>         that works NOT ONLY AT CREATION TIME. Besides from that, I
>         couldn't iconify my whole application by iconifying the main
>         window any more.
> 
I don't know how to solve your main problem; however, on the question
of the whole application iconifying with the main window or not, what
I have noticed is that this works properly when each XmDialogShell is
made the child of the container widget which is the sole child of the
XmDialogShell one level higher up.  Any other relationships seem to
mess-up the iconification.

If you are using XmCreateFormDialog (for example), you will have to
do something like this:

            app_shell = XtInititalize (...)
            main_win = XmCreateMainWindow (app_shell, ...)
            work_area = XmCreateForm (main_win, ...)
            level2 = XmCreateFormDialog (work_area, ...)
            level3 = XmCreateFormDialog (level2, ...)

Note that I have not shown the widgets (pushbuttons, menus, etc.) that
are needed to have the user open the dialogs, the XmCreateFormDialog
calls would go in the callback functions of those widgets.

Note also that XmCreateMainWindow works a little differently from the
general rule; can omit it if you don't need it.

Doing things this way, the dialogs usually come up centred on the
widget that generated the callback (even though it's not formally
in the hierarchy for the new dialog), whether the mouse or keyboard
was used to generate the callback.  On some callbacks triggered by
the keyboard (in particular the Help() action), the triggering
widget is unmanaged before the new dialog is created; the new dialog
then seems to come up almost as far away as possible from the location
where the triggering widget used to be.  Isn't motif wonderful!

... Terry
Newsgroups: comp.windows.x.motif
From: tom@open-i.nl (Tom van Peer)
Subject: Available widgets for Motif ?
Organization: Open-i Software B.V.
Date: Tue, 17 Nov 92 07:33:33 GMT
Summary: Who knows what's available

Probably this question maybe found in some FAQ list, but the last list I've
seen dated from june last year...

Does anyone have an overview of available widget sets, either commercial
or Public Domain ?  Addresses, names, phonenumbers, any hint would be
appreciated. If I get a large enough collection of sets I might even
consider summarizing for this forum if there is enough interest.  Thanks,

Tom.
-- 
Tom van Peer
Volmac Open Software, Utrecht
Tel. +31-30-526555
tom@open-i.nl   ...!sun4nl!openi!tom
Newsgroups: comp.windows.x.motif
From: mishra@sbcs.sunysb.edu (Prateek Mishra)
Subject: ..Text widget absorbs control characters..
Organization: State University of New York at Stony Brook
Date: Wed, 18 Nov 1992 23:02:49 GMT


Can anyone some Motif Guru help with the following (small)
problem:

	I have a text widget(s) contained in a bulletin board
	widget. Most "normal" text is absorbed by the text widget
        but I would like various control characters to propagate
	to the parent bulletin board widget and not simply be
	discarded by the text widget as is the case right now.

How can I achieve this? 


please advise,

prateek mishra
Newsgroups: comp.windows.x.motif
From: daniel@moonshine.osf.org (Daniel Dardailler)
Subject: Re: how to prevent child shell resize
Organization: Open Software Foundation, Motif Team
Date: Mon, 16 Nov 1992 16:23:34 GMT

 
|> I have a control panel which has its own window, and is the child of the 
|> main toplevel shell which has the mainwindow, etc. When the user resizes 
|> the main window, the control panel also resizes, wreaking havoc with the 
|> widgets it contains.
|> Any ideas for a fix? Thanks.

Put your control in a scrolled window with scrollbar and clipping.
If your panel is already child of a MainWindow, just setting
the scrollingPolicy to AUTOMATIC should do it.

daniel@osf.org
Newsgroups: comp.windows.x.motif,comp.windows.x
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Subject: Re: X Events
Keywords:  Focus Change Events
Organization: McGill Research Centre for Intelligent Machines
Date: Thu, 19 Nov 92 08:03:46 GMT

In article <Nov17.221052.60162@yuma.ACNS.ColoState.EDU>, wallsj@CS.ColoState.EDU (jeffrey joel walls) writes:

> [...] I am trying to write a Motif/X program that will allow a user
> to click on another window so that I can grab information about that
> window.

Most briefly put, grab the pointer.

In slightly more detail, you need to grab the pointer so that you get
pointer events regardless of where the pointer is.  Check out
XGrabPointer.

> I know there is a way to do this (xwd does it), but I cannot for the
> life of me find it in any documentation

Did you try looking at the xwd source?  That seems to me to be the most
obvious option.  (You want to look particularly at Select_Window in
dsimple.c.)

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
Newsgroups: comp.windows.x.motif
From: pwagner@ejv.com (Peter Wagner)
Subject: Re: positioning SlectionBox buttons
Date: Tue, 17 Nov 92 10:14:44 EST
X-Received: by usenet.pa.dec.com; id AA11390; Tue, 17 Nov 92 07:18:56 -0800
X-Received: by inet-gw-2.pa.dec.com; id AA07859; Tue, 17 Nov 92 07:18:51 -0800
X-Received: from forty-two.ejv.com by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)
	id AA03976; Tue, 17 Nov 92 10:18:31 -0500
X-Received: from ejvdev4 by ejv.com (4.1/SMI-4.1)
	id AA12196; Tue, 17 Nov 92 10:15:24 EST
X-Received: from ejvmach59.ejv.com by ejvdev4 (4.1/SMI-4.1)
	id AA00744; Tue, 17 Nov 92 10:14:44 EST
X-To: comp.windows.x.motif.usenet
X-In-Reply-To: deveau@oceanroutes.ns.ca's message of 16 Nov 92 16:00:50 GMT


   > 
   > I would like to explicit position the buttons on a selection box.  Does
   > anyone know how to do this?
   > 
   I'm not sure if this will work or not, but it is what I would try first:

   1. get the widget id with widget=XmSelectionBoxGetChild(...)
   2. unmanage it with XtUnmanageChild(widget)
   3. set the XmNx and XmNy resources on it using XtSetValues(widget,...)
   4. manage it again with XtManageChild(widget)

No, this doesn't work, at least not in the FileSelectionBox.  The
problem is that the widgets' positions are managed by a resize
callback on the BulletinBoard widget (that's what I've deduced
anyway), so their x & y settings get changed in the callback after the
widget is managed and any time the dialog is resized.  So the solution
looks to be a bit trickier.  Anyone?

	>peter
From: deveau@oceanroutes.ns.ca ("Terry J. Deveau")
Newsgroups: comp.windows.x.motif
Subject: Re: positioning SlectionBox buttons
Date: 16 Nov 92 16:00:50 GMT
Distribution: inet
Organization: Oceanroutes Canada Inc.

> 
> I would like to explicit position the buttons on a selection box.  Does
> anyone know how to do this?
> 
I'm not sure if this will work or not, but it is what I would try first:

1. get the widget id with widget=XmSelectionBoxGetChild(...)
2. unmanage it with XtUnmanageChild(widget)
3. set the XmNx and XmNy resources on it using XtSetValues(widget,...)
4. manage it again with XtManageChild(widget)

If this doesn't work you may have to use the supplied button closest
to the position you had in mind and change the label, etc. to make
it look and act like the button you wanted to have in that spot.

... Terry
From: hops@x.co.uk (Mike Hopkirk)
Newsgroups: comp.windows.x.motif
Subject: Re: Motif package for Sun
Date: 16 Nov 92 10:18:27 GMT
	<BxI3qC.HI9@netnews.jhuapl.edu> <1992Nov13.145202.19911@drd.com>
Organization: IXI Ltd.


>Subject: Motif Request
>Date: Wed, 04 Nov 92 11:24:10 -0500
>From: romeo@osf.org
>Status: OR
>
>Daniel,
>
>If are looking for Motif binaries to run on the Sun you can contact on of
>the following vendors and they can assist you with that:
>
>ICS	617/621-0060
>Quest	408/496-1900
>SI Sys	403/264-4343
>
>
>If it is the Motif Source Code you are interested in please forward me your
>mailing address and I can send you out the Motif 1.2 Licensing Kit.  
>
>If you have any further questions please let me know.
>
>Thanks,
>Maribeth Romeo
>OSF Direct Channels
>617-621-7300

>>>>> On 13 Nov 92 14:52:02 GMT, mark@drd.com (Resident.Alien) said:

ml> Any reason why IXI was left off the list?  
ml> They offer run-time and development Motif licenses in addition to 
ml> their X.Desktop product. Just a customer and all that.


We would be quite interested in the answer to that question also.

--
Everything disclaimed (including disclaimer)
------< hops@x.co.uk >------< hops@ixi.uucp >------< ...!uunet!ixi!hops >----
Mike Hopkirk ( hops )  |     Coding: When in doubt, use brute force.
IXI Ltd                !                   Ken Thompson. Bell labs
From: tchal@tmchome.UUCP (Thomas M. Chalfant)
Newsgroups: comp.windows.x.motif
Subject: Re: Motif 1.2 clients crash OW3 server?
Date: Thu, 19 Nov 92 21:09:55 EST
Distribution: world
Organization: My house

ron@topaz.bds.com (Ron Natalie) writes:

> |o One person said that ICS Motif 1.2 had been confirmed by ICS to be
> |  buggy, and he switched back to Motif 1.1.4.  He had tried a patch to
> |  xnews (didn't say which one), but it didn't help.
> 
> Sun lies.  Xnews sucks big time.  Both FrameMaker and our product are known
> to crash Xnews through no fault of the application.  I'll certainly be glad
> when sun switches back to using plain X.
> 
> -Ron
Sorry to hear your app bombs the OW3 server, but it makes me happy to know
others experience the same problems as I do.  I have an app which registers
an event handler for the 3rd mouse button in order to post a popup menu over
a dialog.  Works fine on the MIT server and several X Terminals with servers
based on MIT, but blows up the OW3 server.  Island Write, Paint & Draw have
the exact same problem as me, but Sun still hasn't come up with a patch to
their server.  I heard on the net somewhere there were companies selling
versions of Motif with work-arounds included for the OW3 server, but this
seems like a poor way to solve my problem.  Sun just is not interested if it
is a Motif related problem, even if the problem is theirs!

Tom
Newsgroups: comp.windows.x.motif
From: daniel@juliet.osf.org (Daniel Dardailler)
Subject: Re: Scrolling in File Selection Dialog Box
Organization: Open Software Foundation, Motif Team
Date: Mon, 23 Nov 1992 15:35:56 GMT

|> I know
|> XmFileSelectionBoxGetChild (fs, XmDIALOG_DIR_LIST)
|> can return the XmList widget, but what about
|> the scrolled windows. Please help.

Use XtParent.
 
|> Also I have a question of about memory, I always write
|> my programs like this:
|> 
|> XtSetArg (args[0], XmNlabelString, XmStringCreateSimple("aaa"));
|> ...
|> 
|> Is that OK? Or I have to do:
|> 
|> labelstr = XmStringCreateSimple("aaa");
|> ..
|> XtSetArg (args[0], XmNlabelString, labelstr);
|> ..
|> XmStringFree (labelstr);
|> 
|> 
|> Which has a better memory management?
 
The second is the valid one, the widgets always copy the string internally.
Newsgroups: comp.windows.x.motif
From: dealy@kong.gsfc.nasa.gov (Brian Dealy - CSC)
Subject: Re: Need subclassing help!?
Reply-To: dealy@kong.gsfc.nasa.gov (Brian Dealy - CSC)
Organization: Goddard Space Flight Center
Date: Fri, 20 Nov 92 14:15:45 GMT



-- 
In article <4312@cvbnetPrime.COM>, dhukill@esprit.prime.com (Dave Hukill x4056 5-1) writes:
> I'm having a problem with a widget I've subclassed under motif. I get the
> following error:
> 
> Warning: 
>     Name: menubar
>     Class: XmRowColumn
>     Attempt to add wrong type child to a homogeneous RowColumn widget
> 
> The code looks like this:
> 
>       shell = XtAppInitialize(&appContext,
> 			      "myWidgetApp",
> 			      NULL,
> 			      0,
> 			      &argc,
> 			      argv,
> 			      NULL,
> 			      NULL,
> 			      0);
> 
>       menuBar = XmCreateMenuBar(shell,
> 				"menubar",
> 				NULL,
> 				0);
>       XtManageChild(menuBar);
> 
>       menuPulldown = XmCreatePulldownMenu(menuBar,
> 					  "menuPulldown",
> 					  NULL,
> 					  0);
> 
>       menuItem = XtVaCreateManagedWidget("menu item",
> 					 xmPushButtonWidgetClass,
> 					 menuPulldown,
> 					 NULL);
>       XtAddCallback(menuItem, XmNactivateCallback, menuItemCallback, NULL);
> 
>       menuButton = XtVaCreateManagedWidget("menu button",
> 					   myMenuButtonWidgetClass,
> 					   menuBar,
> 					   XmNsubMenuId, menuPulldown,
> 					   NULL);
> 
> Obviously, my class is 'muMenuButtonWidgetClass'. The strange thing is that
> the widget works properly. I'm running Quest Motif version 1.1.4 on Sun SPARC.
> I've checked and double-checked the class initializations in the class record,
> and they appear to be fine. I've successfully sub-classed this widget under
> OLIT, but other than the 'core' class, they're quite different.
> 
> Any input on this problem would be greatly appreciated!
> 
> advTHANKSance - 
> Dave Hukill <dhukill@esprit.prime.com>
i think this is because when you create a radioBox or a menubar 
the default for the resource XmNisHomogenous is set to True.
if you set it to false it will probably relieve you of the error messages.
this resource is to ensure that all widgets being placed in the menu are
of the same type. since you put xmPushButtonWidgetClass and myMenuButtonWidgetClass in the menu , you got a warning...


Brian Dealy
dealy@kong.gsfc.nasa.gov

for more info see Heller p. 864
 
Newsgroups: comp.windows.x.motif
From: jwa@controls.ccd.harris.com (Joey Albert)
Subject: Scrolled Lists: problem with unmanage/manage 
Originator: jwa@rs2
Keywords: scrolled list manage
Organization: Harris Controls
Date: Tue, 24 Nov 1992 00:01:07 GMT


I am creating a scrolled list with a call to XmCreateScrolledList.
This function creates a scrolled window and manages it; and creates and returns a list_widget.
I then manage the list widget.

My application then adds items(XmListAddItem) and deletes items (XmListDeletePos).
In order for my interface to remain small, I only manage the list widget when there
are items to display.  In other words, only when XmNitemCount is > 0 do I want the scrolled
list to be visible.  When I've deleted ALL items from
the list I want to unmanage the scrolled list.  I do this by unmanaging the Scroll Window 
that contains the list widget:
	XtUnmanageChild(XtParent(list_widget));

This seems to work fine, my interface resizes when the scrolled list is unmanaged. 
However, when I then try to manage the Scrolled list so that I can then add an item:

	XtManageChild(XtParent(list_widget));

It sits in this manage command---no core dump, no X warning or errors during the entire
execution.  It remains infinitely at that command.

The list widget is managed once at creation--and never unmanaged.
If it helps the scrolled list is a child of a row column.

Any guidance would be very appreciated.

Thanks!

Joey Albert

---------------------------------------------------------------------------
Joey Albert                    Harris Controls Division			
jwa@ccd.harris.com             P.O. Box 430            
Office: 242-5146               Melbourne, FL 32902-0430
Fax:    242-4268               
---------------------------------------------------------------------------
From: u_bornetun@decus.ch
Newsgroups: comp.windows.x.motif
Subject: Re: Query about the Command widget
Date: 18 Nov 92 09:13:14 CET
Organization: DECUS (Switzerland)

In article <1992Nov17.042003.26005@ccu1.aukuni.ac.nz>, sands@ccu1.aukuni.ac.nz (Greg Sands) writes:
> I have a small problem with the XmCommand widget that I cannot see how to fix.
> The difficulties occur when a previous item in the list has been selected and
> executed.  I can now deselect that item OK, but what I want is that when I next
> press the up-arrow key, the selected item will be the last one in the list. 
> Instead, it the one immediately before the one previously selected, as if the
> item had not been deselected at all.  It seems as though the 
> SelectionBoxUpOrDown action routine may be the one to look at, but how would
> I modify it to do what I want?  Basically it would be sufficient to over-ride
> the first arrow-key press, and force it to select the bottom item.
> 
> Thanks for any help you can give with this.
> 
> Greg.
> 
> 
> -- 
> Greg Sands.                           |  Department of Engineering Science
> -----------                           |  University of Auckland           
> g.sands@aukuni.ac.nz                  |  New Zealand.


I had the same problem, and gave up trying to solve it the "proper" way. 
I used a collection of widgets to implement the same functionality. You just
need a scrolled list with the commands and an XmTextField to type in.
Managing the list is easy, and you need event handlers on the text field
for arrow up and down. Use activate callback on the text field to get the 
command.


Ulrika
Newsgroups: comp.windows.x.motif