HDTenEightyP/NetNews huggingface dataset:
From: saha@ivrea.oas.olivetti.com (Sailendra Nath Saha)
Newsgroups: comp.windows.x.motif
Subject: FileList does not get updated in FSBox
Date: 11 Sep 92 19:02:40 GMT
Reply-To: saha@ivrea.oas.olivetti.com (Sailendra Nath Saha)
Organization: Olivetti Research California

Hi Motif Hackers,

	I have a real problem with file selection box. I have my own directory
search procedure and data qualifying procedure. I did not want to have a
file search procedure separately, because directory search procedure
itself takes care of that. So, I set XmNfileListItems, XmNfileListCount,
XmNdirListItems and XmNdirList. Finally, I set XmNlistUpdated to True
and XmNdirectoryValid to False, so that the default file search
procedure does not get invoked.

	Now with these settings, fsbox works fine, except a few times, when it
does not show the file list. All I can see is the scrollbar of the file
list. Somehow the file selection box is squeezing the width of the file
list to zero, I dont know why such a funny behavior. And this happens
arbitrarily.

	Any help, any clue will be appreciated. Thanks for all help.

Saha

Olivetti Advanced Technology Center  | Anticipation of death is worse
saha@oas.olivetti.com                | than death itself.
408-366-3062(Voice)
408-366-3606(Fax)
From: deveau@oceanroutes.ns.ca ("Terry J. Deveau")
Newsgroups: comp.windows.x.motif
Subject: Re: How to make buttons look pressed in ??
Date: 11 Sep 92 14:54:21 GMT
Distribution: inet
Organization: Oceanroutes Canada Inc.

>     I would like to have two push buttons and have them act like a 
>   radio box, where you push one button in and the other "pop" out.
>   Also when you push the button in I would like to have it look as 
>   though it is still pressed in.  I anybody has done this, or seen 
>   it done?  

  String ToggleSet[] = { "one", "two", "three" };
  Widget parent, row, Toggles[XtNumber(ToggleSet)];
  int n, i, nToggles = XtNumber(ToggleSet);
  Arg args[10];
  XmString wrk;

  n = 0;
  MySetArg (args, n, XmNorientation, XmHORIZONTAL);
  MySetArg (args, n, XmNradioAlwaysOne, True);
  MySetArg (args, n, XmNradioBehavior, True);
  row = XmCreateRowColumn (parent, "toggle row", args, n);
  for (i=0; i<nToggles; i++) {
    n = 0;
    wrk = XmStringCreateLtoR (ToggleSet[i], XmSTRING_DEFAULT_CHARSET);
    MySetArg (args, n, XmNlabelString, wrk);
    MySetArg (args, n, XmNindicatorType, XmONE_OF_MANY);
    Toggles[i] = XmCreateToggleButton (row,ToggleSet[i], args, n);
    XtManageChild (Toggles[i]);
    XmStringFree (wrk);
  }


... Terry
From: felix@laas.fr (Francois Felix INGRAND)
Newsgroups: comp.windows.x.motif
Subject: Re: Redirecting Standard Output to a Widget? (candicate for FAQ???)
Date: 11 Sep 92 07:14:19 GMT
Organization: LAAS-CNRS France
In-reply-to: armin.kuepfer@alcatel.ch's message of 9 Sep 92 08:19:09 GMT

In article <1992Sep9.081909.16128@alcatel.ch> armin.kuepfer@alcatel.ch (Armin Kuepfer) writes:

   From: armin.kuepfer@alcatel.ch (Armin Kuepfer)
   Newsgroups: comp.windows.x.motif
   Date: 9 Sep 92 08:19:09 GMT
   References: <1992Sep8.235519.8543@ncsu.edu>
   Sender: armin@srztt215.alcatel.ch (Armin Kuepfer)
   Organization: chx400.switch.ch
   Lines: 8

   > Is it possible to redirect standard output to a widget?

This question comes back every two weeks... It could be a good candidate for
the FAQ.

   You might look at xdbx, which is a X frontend for dbx, you could

I believe, this solution use pseudo tty... This may not be appropriate (see
bellow)

   check W. Richard Stevens new excellent book 
     "Advanced Programming in the UNIX Environment", 
     Addison Wesley ISBN 0-201-56317-7, 
   for input/output handling in parent and child processes and you yse 
   XtAppAddInput() to read the childs data.


There are basically 2 possibilities. Either you want the *same* program to output
its stdout in one of its text widget, or you want another program to do the
output for you.

In the second case indeed, a xgdb kind of solution is fine (you basically
put a front end to your old application). No problem, there are hundreds of
programs doing thatout there, just look at their code.

In the other (the first one) case, you need an "echo like" program, started
with fork, which will send you back on a specified socket whatever you send it.
You get the sockets with a socketpair call before the fork, and from the
parent, you will register the socket to Xt with XtAppAddInput(). Note that if
you want a general mechanism, and want to make sure that it will work in any
situation, you need the other process (the echo like program) to be able to
buffer any amount of data (otherwise you may deadlock). Similarle, if you know
that your data will not ever exceed 4k (or whatever the socket buffer size is),
then you do not even need the echoprogram... Just the socketpair will do (after
all a socket can be considered as a "free" buffer). But this is very risky and
I would not recommend this solution

Anyway, this 2 processes solution with an echo like program works wery well for
a program I wrote. I can pass piece of dirty, badly commented, unreadable, non
guarantee code if desired.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Francois Felix INGRAND                   "Read my Lisp... No new syntax" (nil)
LAAS/CNRS: felix@laas.fr      "La guerre, qu'on voit danser le long des golfes
ACS Technologies                     clairs, a des reflets d'argent" (Anonyme)
Newsgroups: comp.windows.x.motif
From: rupen@smurf.ssc.gov (Rupen Sheth)
Subject: Young's C++/Motif Application Framework library
Organization: Superconducting Super Collider Laboratory
Date: Tue, 15 Sep 1992 21:21:30 GMT

Douglas Young's example source for an Application Framework has filenames which are longer
that 15 chars.  As a result, when creating the library 'ar' truncates the filenames when adding it
to the library.
I end up getting unresolved member functions when using the library.

How have others fixed this problem.

Using Quest systems X11R5, Motif 1.1.4 on Sun Sparc running SunOS 4.1.1

Please respond via email.
Thank you.

-- 
Rupen Sheth
Superconducting Super Collider Laboratory        EMail: rupen@falcon.ssc.gov
2550 Beckleymeade Ave. MS 4004                   Phone: (214) 708-3344
Dallas, TX 75237                                   FAX: (214) 708-4827
Newsgroups: comp.windows.x.motif
From: drand@spinner.osf.org (Douglas Rand)
Newsgroups: comp.windows.x.motif
Subject: Re: How to keep F10 from activating menubar?
Date: 9 Sep 92 23:14:49 GMT
	<1992Sep9.145026.13795@cbnewsc.cb.att.com>
Organization: Open Software Foundation

In article <1992Sep9.145026.13795@cbnewsc.cb.att.com> dwd@cbnewsc.cb.att.com (David W. Dykstra) writes:

   In article <1992Sep4.222553.8316@cbnewsc.cb.att.com> I asked how
   to override the behavior of F10 activating a window's menu bar.
   After further experimentation, it appears there's only one way to
   do it: by specifying a different key combination for osfMenuBar
   in the defaultVirtualBindings application resource.  (By the way,
   note that defaultVirtualBindings is not a resource of any widget,
   and must be specified in the resource database from an external
   file or the command line, before XtInitialize() is called.)

   I tried overriding the translation of the <Key>osfMenuBar event in
   the widget of interest and every one of its ancestors, but that had
   no effect.  It's almost as though osfMenuBar generates a different
   kind of event than a plain <KeyPress>.  From the description of
   accelerators in the O'Reilly manual, this seems like the mechanism
   that should be used to implement the osfMenuBar function, but since
   accelerators are just an extension of event translations, Motif must
   be doing something else.

   If anyone can explain the mechanism that's used any better, or show
   another way to override it, I'd still be interested.

You're right, we are.  We use grabs and event handlers to implement
accelerators.  Sometime when I have more time,  I'll tell the world
all the reasons.  Suffice it to say that we cannot easily change
this and have Motif work correctly.

On a different issue,  why do you want to break this?  There are
quite good reasons to have all apps use the same key to activate
menus.  Why not allow your users this luxury.

--
Douglas S. Rand <drand@osf.org>		OSF/Motif Dev.
Snail:         11 Cambridge Center,  Cambridge,  MA  02142
Disclaimer:    I don't know if OSF agrees with me... let's vote on it.
Amateur Radio: KC1KJ
From: patrick%8461.span@FEDEX.MSFC.NASA.GOV (Patrick E. Meyer (205)544-2265)
Newsgroups: comp.windows.x.motif
Subject: XmList Callbacks, and Keyboard events..
Date: 10 Sep 92 20:01:19 GMT

Any Help appreciated...

Question 1:

When the user selects and deselects on an item in a List the appropriate
selection callback is called. Do any selection callbacks get called during
XmListDeselectAll? If so, which one. The manual does not indicate that one is
called, but it seems likely that one should.

Question 2:

I would like to create a library function that when called will install a
keyboard event to catch "ctrl<key>[" on the main shell.  This must be caught
like MWM alt+F? keys do (like alt+F4 is close).  I have tried:

A. Using XtAddEventHandler. The keyboard events are not received.

B. Adding a translation. The keyboard events are not received.

C. XSelectInput. The keyboard events are not received.

D. After studying and studying I noticed other pull-downs with accelerators
that received keyboard events.  I emulated them and it semi-worked for simple
combinations of Bulletin Boards and Drawing Areas, but for applications where
the interface became levels deep the events stopped coming.  More
studying...more reading...only to discover that with pull-downs they added the
resource traversalOn True.  This helped when I went through all the primitive
classed widget and set the traversalOn resource. 

There has got to be an easier way...I just looking in the wrong place and not
seeing the Tree for the Forrest! Any help?

Thanks in advance

Patrick
==========================================================
Patrick Meyer       email: patrick%8461.span@Fedex.Msfc.Nasa.Gov
		       or: pmeyer%mips9.span@Fedex.Msfc.Nasa.Gov
From: et11hkh@sbusol.rz.uni-sb.de (Rainer Zewe)
Newsgroups: comp.windows.x.motif
Subject: Problem with positioning an Options-Menu
Date: 11 Sep 92 07:12:21 GMT

I have a problem with positioning the size of an option-menu,
which is a child of a form-widget. The postition is selected
with the XmATTACH_POSITION for top, bottom, left and right.
When I leave the size of the form-widget undefined, it is 
automatically set to 649x638 pixels. When I set the size of
the form-widget with the width- and height-resource, the
options-menu is not visible, even when I select the 649x638
size.

Here is a small demo-program that shows the effect:

----------------------------------------------------------------------

#include <Xm/Form.h>
#include <Xm/PushB.h>
#include <Xm/RowColumn.h>

Widget  initOptionMenu();

main( argc, argv )

int   argc;
char  **argv;

{
XtAppContext	context;
Widget		AppShell;
Arg		args[1];

AppShell = XtAppInitialize( &context, "Options", NULL, 0, &argc, argv, NULL, args, 0 );

initWidgetTree( AppShell );

XtRealizeWidget( AppShell );

XtAppMainLoop( context );
}


initWidgetTree( AppShell )

Widget  AppShell;

{
Widget	MainW;
Widget	OptionMenu;

MainW = XmCreateForm( AppShell, "MainW", NULL, 0);
XtManageChild( MainW );

OptionMenu = initOptionMenu( MainW );
}


Widget  initOptionMenu( parent )

Widget  parent;

{
Widget  ColourMenu, ColourOptions;
Widget  Colour1Button, Colour2Button;
Arg     args[10];

ColourMenu = XmCreatePulldownMenu( parent, "ColourMenu", args, 0 );

Colour1Button = XmCreatePushButton( ColourMenu, "Colour1", args, 0 );
XtManageChild( Colour1Button );

Colour2Button = XmCreatePushButton( ColourMenu, "Colour2", args, 0 );
XtManageChild( Colour2Button );

XtSetArg( args[0], XmNsubMenuId, ColourMenu );
XtSetArg( args[1], XmNtopAttachment, XmATTACH_POSITION );
XtSetArg( args[2], XmNbottomAttachment, XmATTACH_POSITION );
XtSetArg( args[3], XmNrightAttachment, XmATTACH_POSITION );
XtSetArg( args[4], XmNleftAttachment, XmATTACH_POSITION );
ColourOptions = XmCreateOptionMenu( parent, "ColourOptions", args, 5 );
XtManageChild( ColourOptions );

return( ColourOptions );
}

----------------------------------------------------------------------

and this is the resource-file with the size of the form-widget:

----------------------------------------------------------------------

*width:		649
*height:	638

*ColourOptions*labelString:	colour :
*ColourOptions*topPosition:	46
*ColourOptions*bottomPosition:	51
*ColourOptions*leftPosition:	25
*ColourOptions*rightPosition:	61

----------------------------------------------------------------------

Thanks for help, rainer.

----------------------------------------------------------------------

Rainer Zewe				Tel.:	49 681 302 4182
Universitaet des Saarlandes		e-mail:	et11hkh@sbusol.rz.uni-sb.de
Lehrstuhl fuer Energieversorgung

Newsgroups: comp.windows.x.motif,comp.sys.hp
From: andy@infotec.ch (Andrew Warinner)
Subject: Problem setting clientAutoPlace in HP Motif!
Keywords: Motif, X, HP, Motif-sucks-eggs
Organization: Infotec S.A.
Distribution: comp
Date: Mon, 14 Sep 1992 15:31:42 GMT


I am having a problem with setting the Motif resource "clientAutoPlace"
in HP Motif.  I set the resource in my .Xdefaults file as follows:

	Mwm*clientAutoPlace:            False
	Mwm*defaults*clientAutoPlace:   False

For good measure, I load another resource file containing the
same definitions as above with "xrdb -load <resource file>" before
running the application.  There is no mention of clientAutoPlace in 
resource files in the usual places (/usr/lib/$LANG/app-defaults, 
/usr/lib/app-defaults, $XAPPLRESDIR, $XENVIRONMENT, etc).  A "xrdb -query" 
shows the clientAutoPlace resource set as above.  But HP Motif still 
autoplaces the windows (even if I restart Motif, log out and log back 
in, start the app from another shell, etc).

I have no problems with this on Sun Motif and IBM Motif.  Does the vue 
manager save or change clientAutoPlace so that is overriding my setting?

Thanks in advance,

Andrew Warinner				"Semper ubi sub ubi"
(andy@infotec.ch)			Infotec S.A.
phone: 022/738 44 33			8 avenue de Frontenex
fax:   022/786 50 61			1207 Geneva, Switzerland
Newsgroups: comp.windows.x.motif
From: rm@hounix.org (Rohit Mehrotra)
Subject: How Do I Prevent Motif From Grabbing Keys
Organization: Houston UNIX Users Group (HOUNIX), Houston, TX
Date: Sun, 13 Sep 1992 15:00:06 GMT


Hi Everybody,

Is their an easy way to prevent motif/mwm from grabbing these keys:
	Alt-[Function Keys]
	F10 etc

My application coming from OpenLook needs these keys and I do NOT CARE
if the application would not be Motif compliant. Ideally I would like
to have these keystrokes turned off only for my application, i.e. 
let them be passed to my application instead of getting interpreted
by the Window Manager.

I would really appreciate if someone can EMAIL me a solution. I have
been struggling for a long time with this issue.

Thanks

Rohit

-- 
RM

EMAIL: rm@hounix.org
Ph: 713-781-7406
Newsgroups: comp.windows.x.motif
From: shmdgljd@rchland.vnet.ibm.com (Jay Schmidgall)
Subject: Q: Mwm beep when type on root ?
Date: Fri, 11 Sep 1992 15:45:47 GMT
Reply-To: jay@vnet.ibm.com
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester, MN

Recently I had someone ask me if it was possible to have mwm beep when they
started typing and the pointer was where a window wasn't.

I thought, sure, just add a key binding like

<Key>	root	f.beep

to your DefaultKeyBindings and you'd be set.  However, this didn't work;
I had to do

<Key>a	root	f.beep
<Key>b	root	f.beep

and so on to get it to work like they wanted.

``<Key>'' is a valid event for tranlations, so why doesn't mwm understand
it?

-- 
: jay          jay@vnet.ibm.com    My opinions and ideas, not my employer's.
: shmdgljd@rchland.vnet.ibm.com    (c) Copyright 1992.  All rights reserved.
From: jrh@de.deere.com (John R. Howell)
Newsgroups: comp.windows.x.motif
Subject: Re: nfs over X.25???
Date: 15 Sep 92 15:49:08 GMT
Followup-To: comp.windows.x.motif
Organization: Deere & Company

In article <jrh-140992101026@coyote.de.deere.com>, jrh@de.deere.com (John
R. Howell) wrote:
> 

[ nothing having anything to do with motif ]

woops, sorry.  I sent this to the wrong newsgroup.

John
Newsgroups: comp.windows.x.motif
From: roland@ecf.toronto.edu (Roland Ramjist)
Subject: Re: XmForm Widget  [seems like a bug -- cannot set margin]
Keywords: marginHeight, marginWidth etc
Organization: University of Toronto, Engineering Computing Facility
Date: Mon, 14 Sep 1992 23:42:00 GMT

anil@microware.com (Anil Purohit) writes:
>Why does the form refuse to have a marginHeight of 20. 

The XmForm widget appears to completely ignore marginHeight in Motif 1.1.
I have no explanation.  Call it a bug?


That's not all.  Motif 1.1 seemed to have changed the interpretations of
several such properties, without any concern for upward compatibility or
coherence or documentation.  Here's a few others I'm grappling with:

 - marginWidth and marginHeight have no effect, but even more neat,
   horizontalSpacing and verticalSpacing were tampered with,
   so that you have no way of telling a form to leave any kind
   of margin around the enclosed widgets.
   (The horizontal/verticalSpacing resources used to enforce spacing
   between widgets AS WELL AS between widgets and the enclosing form,
   Not any more.  Now the form shrinks (clunk) down until it presses
   presses up against your rightmost/bottommost widgets.)

 - one way to get out SOME instances of the problem above is
   to do the insane, and attach the right/bottom of the enclosed
   widgets to the form.  The bizarre happens.  The form (which
   is now supposedly determining the size to the enclosed widgets)
   now instead resizes to enclose the widgets inside (getting its
   size from the widgets).  This "solution" does not work if you
   have more than one variable-sized thing inside the form which
   might "extend" the size of the form (a common situation in well-
   designed interfaces, I would think.)

 - The bottomOffset and rightOffset no longer have any effect unless
   the associated attachments are other than XmATTACH_NONE.  It used
   to be that you could use these to get a margin.  It worked, although
   it didn't really make a lot of sense to have offsets work here.

Is there any decent description of these subtler points of forms?

Tim
From: snail@lsl.co.uk
Newsgroups: comp.windows.x.motif
Subject: Re: How do you set an option menu value by program?
Date: 7 Sep 92 12:32:12 GMT
Distribution: comp
Organization: Laser-Scan Ltd., Cambridge

> and it works fine when the user select various values... But how do you change
> the value by program? (we want to reset the menu to a default value when we
> reset the application).
> 
> I have not been able to find the solution in all the book I checked... 
> There must be a way...
> 
> Thanks in advance,

Set the resource XmNmenuHistory to the widget ID of the pushbutton that you
want selected on your OptionMenu.

snail@lsl.co.uk      

Interviewer: "What's the most satisfying thing about being in
              The Sisters Of Mercy?"
Eldritch:    "When I collapse at the end of it..."
Interviewer: "Do you mean that?"
Eldritch:    "Yeah...."

Vote for Bill Clinton. Vote for Bill Clinton. Vote for Bill Clinton.
From: dansmith@autodesk.com (Daniel Smith)
Newsgroups: comp.windows.x.motif
Subject: Re: Help on XtMainLoop
Date: 11 Sep 92 19:01:17 GMT
Distribution: inet
Organization: The Internet

> > > Venkatesh Bmuthanna wrote about "Help on XtMainLoop":
> 	I have to develop  an user interface for an expert system  
> which does not allow me to use the XtMainLoop, hence i am trying to  
> write a code which would perform the functions of XtMainLoop. I don't  
> have any idea about this and will appreciate any help in this matter.

	[you didn't have a return address (news?...), so here goes...
	this seems to come up often enough to go in the FAQ]

	This is from Event.c in the X11R5 distribution:

void XtAppMainLoop(app)
        XtAppContext app;
{
    XEvent event;
 
    for (;;) {
        XtAppNextEvent(app, &event);
	/* put whatever you need here.... */
        XtDispatchEvent(&event);
    }
}

	btw, XtMainLoop just looks like:

 
void XtMainLoop()
{
        XtAppMainLoop(_XtDefaultAppContext());
}



				Daniel
From: tonyf@ims.com (Antonio Freixas)
Newsgroups: comp.windows.x.motif
Subject: Re: How to keep F10 from activating menubar?
Date: 11 Sep 92 15:09:49 GMT
Reply-To: tonyf@ims.com
Organization: Integrated Measurement Systems, Inc.

In article <DRAND.92Sep9181450@spinner.osf.org>, drand@spinner.osf.org (Douglas Rand) writes:
|>
|> On a different issue,  why do you want to break this?  There are
|> quite good reasons to have all apps use the same key to activate
|> menus.  Why not allow your users this luxury.
|> 
|> --
|> Douglas S. Rand <drand@osf.org>		OSF/Motif Dev.
|> Snail:         11 Cambridge Center,  Cambridge,  MA  02142

-- 

I'm not the person for whom you addressed the question, but I'll give
you an answer anyway.

The last project I worked on was an X11/Motif port of a program that
our users had used first on PC's and then on SunView.  F10 was used as
one of 10 related operations one could perform.

I decided to keep all the PC/SunView bindings intact so that users
would not have to relearn the key bindings.  If I could have moved
F1-F10 to some other reasonable binding, I would have done so, but it
is difficult to find another set of 10 keys that are so well related
(by the way the Shift and Ctrl versions of the F1 - F10 keys were also
used and I leave the Alt keys available for the window manager).

So, I didn't feel that I had any other good alternative.  I did make
the change in the app-defaults file so the user could switch back to
the standard OSF style if he/she wanted to.

As to the value of F10 for the typical user -- the engineers here at
IMS have been using Motif for a while.  Besides the two X11/Motif
"gurus" (myself being one), most users are not aware that F10 has a
special meaning.  Of the ones who do, few use the feature (including
myself).

I like to keep things as standard as possible.  In this case, however,
the compatibility we lost is hardly used and the compatibility we
gained (with our previous software) is of more value.  And we gave the
user the option of restoring totally standard behavior (but then they
have to decide what to do with the function normally tied to F10).

					         -- tonyf@ims.com
					       (503) 626-7117 x1349
Newsgroups: comp.windows.x.motif
From: cecchinr@hornsby.cs.rpi.edu (Ron Cecchini)
Subject: Is there something analogous to XtIsMapped() ?
Organization: Rensselaer Polytechnic Institute, Troy, NY
Date: Wed, 9 Sep 1992 17:55:17 GMT

Hi,

  There is XtIsManaged() and XtIsRealized().  I need XtIsMapped() and
there is none.  What is the easiest way to detect this (I'm not
having any luck trying to use the widget's resources).

Ron

p.s. I just discovered that my mail was screwed up.  So, if anyone
      replied to my previous question(s) about SelectionBoxes and
       multiple fonts, could you please send me the answer again (or
       post it here, which would be better...)


Newsgroups: comp.windows.x.motif