HDTenEightyP/NetNews huggingface dataset:
From: daniel@juliet.osf.org (Daniel Dardailler)
Subject: Re: Problem Exiting from a Dialog?
Keywords: 
 
Organization: Open Software Foundation, Motif Team
Date: Mon, 21 Dec 1992 14:50:17 GMT

|> I have created a dialog window and set up the callbacks
|> for the _okButton and _cancelButton, then I added some
|> textEditFields to the dialog window. BUT whenever you 
|> type a carriage-return in one of the textFields the
|> dialog exits??  I only want the dialog to exit when 
|> one of the _OK or _CANCEL buttons??
 
Style guide requirement binds the return and the ok activation in
most Dialog boxes.
BulletinBoard enforces the style guide as much as it can.
If you want to mess up with the style guide, you'll have to
mess up with BulletinBoard (translation table in this case).
From: marmor@bimacs.BITNET (Eli Marmor)
Newsgroups: comp.windows.x.motif
Subject: Motif-based editor
Keywords: Motif,editor,XmText
Date: 21 Dec 92 17:48:49 GMT
Organization: Math & CS, BarIlan U, Ramat-Gan, Israel


Hi,
I'm looking for a good Motif-based editor, with menus, help,
searches, replaces, etc. I need a public-domain one, with available source.

I imported Asedit, and it looks fine, but it can't load big files.
I guess it is Motif fault, but maybe there is an editor which holds in its
Text-widget only the visible characters (by handling by himself all the jobs
which are done automatically by scrolled-window).

If you know about an editor which acts this way, or an editor which is better
than Asedit, please inform me.
If I get information about many editors, I'll sum the responses in a table,
and send it to the news-group.

                                ThanX in advance,
                                                Eli Marmor
Xref: sparky comp.windows.x.motif:8187 comp.windows.x.intrinsics:682
From: mbr0@roger.gte.com (Mark Rosenthal)
Newsgroups: comp.windows.x.motif,comp.windows.x.intrinsics
Subject: Help with MrmFetchWidget() and XtDestroy()
Date: 23 Dec 92 00:38:10 GMT
Followup-To: comp.windows.x.motif
Organization: GTE Laboratories


I have an application in which there can be an arbitrary number of dialog
shells created using the same template.  I am using UIL and creating the
shell and its children with MrmFetchWidget().  When the user clicks on the
close button in the dialog, the close callback calls XtDestroy() on the dialog.
The next time the user asks for a dialog from the same template and
MrmFetchWidget() is called the code crashes with a segmentation violation.

Does anybody know of anything to watch out for when using MrmFetchWidget()
and XtDestroy()?

	mbr0@gte.com
Newsgroups: comp.windows.x.motif
From: koverber@cs.ulowell.edu (Kurt Overberg)
Subject: Help with freaking out XmText?
Originator: koverber@bigmax.ulowell.edu
Organization: University of Massachusetts at Lowell Computer Science
Date: Wed, 30 Dec 1992 15:22:24 GMT



Hello, 

	Im currently trying to brain-damage a XmText Widget.  Ok, 
here is what i want it to do...

Imagine a password requester.  All I want to happen is when I type
into the text field, instead of putting the characters there, I want
asterixes ("****" to appear.  Has anyone done this?  I have tried a 
few way, but it looks like it may have to be a major hack.  Things
I have tried:

Everytime a key is pressed (XmNmodifyValueCallback) i call the action-procedure
"delete-previous-character", to delete the character and then I 
do a XmTextInsert to insert the *.  This core dumps seriously.
I don't know why, so if anyone has any ideas, PLEASE let me know...
Thanks!

						peace out.

						    kurt

-- 
Kurt Overberg            | I honestly doubt you care about my opinions ;^)      
U of Mass, Lowell        | "Poke a double-decker on a Llama taboot,       
koverber@cs.ulowell.edu  |  Llama taboot, taboot!"      -Phish
From: ramakris@csgrad.cs.vt.edu (S.Ramakrishnan)
Newsgroups: comp.windows.x.motif
Subject: Re: Centering button in form ?
Date: 24 Dec 92 02:12:06 GMT
Organization: VPI&SU Computer Science Department, Blacksburg, VA

In article <1992Dec23.142215.9700@osf.org  > daniel@juliet.osf.org (Daniel Dardailler) writes:
  
  >|>  -------------------------------
  >|> |       ----------------        |
  >|> |      |                |       |
  >|> |       --XmPushButton--        |
  >|>  ------------------------XmForm-
  
  
  >Form does not support center attachment as a resource.
  >You'll need to do some programming.
  >
  >You have to wait for after the Form first layout to be sure everybody
  >got its natural size (the button and the form here).
  >(unless you want to fix the sizes of your widgets, which is very bad).
  >
  >Calling a routine after XtRealize and before the main loop is fine.
  >
  >In this routine, do something like:
  >
  >        n = 0;
  >	XtSetArg (args[n], XmNwidth, &width);  n++;
  >	XtGetValues (push, args, n);
  >
  >	n = 0;
  >	XtSetArg (args[n], XmNleftAttachment, XmATTACH_POSITION);  n++;
  >	XtSetArg (args[n], XmNleftPosition, 50);  n++;
  >	XtSetArg (args[n], XmNleftOffset, -((int)width)/2);  n++;
  >	XtSetValues (push, args, n);

This fragment of code is likely to yield funny results. 
XmNleftPosition indicates not the x-coordinate but the 50th grid 
position where the number of grid elements is set by XmNfractionBase (a
form resource). Setting XmNleftPosition == 50 when XmNfractionBase is not 
set is likely to yield strange results (I wonder if the pushbutton will 
even be seen).

Further, when the left attachment type is XmATTACH_POSITION (placement
by grid), specifying XmNleftOffset is meaningless.

Coming back to the original problem: trying to centre the *only* child of
a form using XmATTACH_POSITION seems impossible, since the grid
points are computed considering the size of the form at the time of
realization. Since form wraps around its only child tightly,
you are basically defining the positions on the child itself.
Hence you end up trying to position the child on the parent using a grid
that is defined on the child !


---
S Ramakrishnan, CS Dept, McBryde Hall, VaTech
Xref: sparky comp.windows.x.motif:8160 comp.windows.x:20453
Newsgroups: comp.windows.x.motif,comp.windows.x
Subject: Question on default actions
From: bobhays@spss.com (Bob Hays)
Date: Mon, 21 Dec 1992 19:51:57 GMT
Organization: SPSS, Inc.

We're using AIX 3.2.2, OSF/Motif 1.1.2, X V11 R4.

We're trying to use default actions for pushbuttons, but list
behaviors are getting in the way.  If a listbox has focus, and a user
presses return, the default list action occurs and the default push
button is pressed.  This causes problems in some cases:-)  How are
others handling this?  We want to have return do the default action
for the dialog w/o doing the list action - can this be done?

Thanks and have fun! - Bob

-- 
===============================================================================
The opinions expressed above are those of Bob Hays and not SPSS, Inc.
 bobhays@spss.com  Phone: (312) 329-3529 | "I'm hovering like a fly, waiting
                   Fax:   (312) 329-3657 |  for a windshield on a freeway" -PG
From: drand@spinner.osf.org (Douglas S. Rand)
Subject: Re: Is it possible to get at FileSelectionBox PushButtons?
Organization: Open Software Foundation
Date: 31 Dec 92 11:21:47

In article <3243@contex.contex.com> avinash@felix.contex.com (Avinash Chopde) writes:
   ...
   *XmFileSelectionBox.translations: #override \n\
	   <Btn2Down>,<Btn2Up>:	ManagerGadgetActivate() \n\
	   <Btn2Down>:	ManagerGadgetArm() \n\
	   <Btn2Up>:	ManagerGadgetActivate()

   ...
   *XmMessageBox.translations: #override \n\
	   <Btn2Down>,<Btn2Up>:	ManagerGadgetActivate() \n\
	   <Btn2Down>:	ManagerGadgetArm() \n\
	   <Btn2Up>:	ManagerGadgetActivate()

I will point out that you are using the button normally
used for drag and drop.  You should consider the implications
of this for your users.  One of the reasons to use a particular
widget set is the expectation that users will know the semantics
of the controls.  The above would,  for example,  prevent 
dragging from a label in the FileSelectionBox.


--
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
Newsgroups: comp.windows.x.motif
From: nigelc@cognos.com (Nigel Campbell)
Subject: commerical products and MOTIF
Organization: Cognos Incorporated, Ottawa CANADA
Date: Wed, 30 Dec 1992 16:02:55 GMT

Is there an FAQ archive that contains reviews on the implementation
of the MOTIF GUI in commerical 4GL tools ? Anyone want to comment
on their experiences ?


-- 
Nigel Campbell          Voice: (613) 738-1338 ext 3016    P.O. Box 9707
Cognos Incorporated       FAX: (613) 738-0002             3755 Riverside Dr.
Database and Connectivity MCI: nigel campbell || 307-4729 Ottawa, Ontario
UUnet: nigelc@cognos.COM                                  CANADA  K1G 3Z4
From: dickie@schaefer.math.wisc.edu (Garth Dickie)
Newsgroups: comp.windows.x.motif
Subject: specifying a visual class and depth
Date: 30 Dec 92 19:43:49 GMT
Reply-To: dickie@math.wisc.edu
Organization: Univ. of Wisconsin Dept. of Mathematics

THe machine that I am working on has a 24bit visual capability, however
the root window is 8bit, and of course windows open 8bit by default.

How do I specify to Motif that I want a specific visualclass and
depth? For example, I would like to open a window which is
	TRUECOLOR and 24bits deep.

(please do NOT respond via email.)

 - joe porkka
From: jsheng@PICA.ARMY.MIL ("Joseph Y. Sheng", IMD-PB)
Newsgroups: comp.windows.x.motif
Subject: Re:  Error: Shell Widget 3 has zero width ...
Date: 23 Dec 92 15:54:58 GMT
Distribution: inet
Organization: The Internet


  I am new to Motif, too.  I noticed that you set the arguments but you never
really implement those changes to the toplevel shell widget.  It should work
if you make the following change.

>>  XtSetArg(args[n], XmNwidth, 200); n++;
>>  XtSetArg(args[n], XmNheight, 200); n++;

    XtSetValues(toplevel,args,n);

>>  BULLETINBD_0 = XmCreateBulletinBoardDialog(toplevel,"BULLETINBD_0",args,n);

...Joe Sheng
   US ARMY
Newsgroups: comp.windows.x.motif
From: matt@sparc6.pisces.macsch.com (Matt Jackson)
Subject: HP Motif vs. xnews
Organization: MacNeal-Schwendler Corp.
Date: Wed, 30 Dec 92 12:49:50 GMT


Found an obscure but annoying problem the other day...

If I run my application on an HP9000 with X11R4 and Motif1.1, and display
it on a SPARC 1+ with Openwin 3.0, it takes about *10 minutes* to start
up (on other machines, it takes a few seconds). The holdup appears to be
in a routine called XRefreshKeyboardMapping(). "hpterm" does the same
thing, but other Motif programs do not. Running Motif programs on an SGI
Indigo and displaying them on the SPARC works like a champ. Running any
application anywhere and displaying it on SPARC using the X11R5 server
works fine, so it appears to be an incompatibility between xnews and HP
Motif 1.1.

Has anybody seen this?
Does anybody know what is causing it?
Does anybody know how I can fix it?

Thanks for you patience and attention.




-- 
-----------------------------------------------------------------
Matt Jackson                           e-mail: m_jackson@macsch.com  
The MacNeal-Schwendler Co. b.v.       Surface: Groningenweg 6
"Lao-tsu never lived in Amsterdam..."          NL-2803 PV Gouda
From: Monica_Lee@smtp.esl.com (Monica Lee)
Newsgroups: comp.windows.x.motif
Subject: Any ideas for a Thermometer widget
Date: 22 Dec 92 16:57:27 GMT
Followup-To: comp.windows.x.motif
Organization: ESL Inc., S'vale CA

I want to create a thermometer widget.  I have the following ideas:

1) use the drawing area widget
2) use the scroll bar widget - if I can turnoff the directional arrows
3) maybe use the scale widget

Does anybody have any additional ideas.  Or rights and wrongs about using
the above ones?

--
Monica
Newsgroups: comp.windows.x.motif
From: sglanger@vela.acs.oakland.edu (LANGER STEVEN C)
Subject: HELP pipe communication?
Organization: Oakland University, Rochester MI.
Distribution: na
Date: Sun, 3 Jan 1993 19:22:40 GMT

Hello all;
 Being , X, Motif programmer for about 3 weeks now, I 
apologise if the next questin is pretty primitive, but here goes.

I've got a foreground X app that launches a child process (non-
graphical) for data acquisition. I want to establish 2-way pipe
communication between said parent-child.

Vol 4 of the Xt Intrinsics Manual by Adrian Nye shows on pg.282-283
how to use popen, but this only gives one way communication and
since the example didn't show how to modify the child, I could
not even get the example to work.

Volume 6, Motif Programming Manual by Dan Heller on pg. 699 says,

1. call pipe to get the input and output channels
2. call fork to spawn the child
3. use dup2 on the child side to redirect stdout and stdin.
4.  use XtAppAddInput to monitor the pipes.

  Sadly, there is no code example of this procedure.

I've since gone to the man pages and I see that pipe(int *fildes)
returns two ints;
	filedes[0] being for read and
	filedes[1] being for write

XtAppAddInput requirs bona fide FILE pointers. How do I get them from
pipes it  returns? Also, my man server knows a total of 2 
sentences about buf2. I really could use a code fragment from both sides
to put this puzzle together.  Any UNIX interprocess communication
GURUS with X experience out there? I'll post a summary of methods
if there is interest.

--thanks in advance, steve


P.S. I'm running an SGI Indigo with Os 4.0.1

-- 
Steve Langer  			       sglanger@argo.acs.oakland.edu (VMS)
Oakland University		       sglanger@vela.acs.oakland.edu (Ultrix)
---------------------------------------------------------------------------
Standard disclaimers apply. In addition, the author makes no guarantees,
concerning the grammatical accuracy of his writing. Therefore, any ^B's, ^C's, 
midword character additions/deletions and other non-sense which occurs (after 
the work leaves the author's decade old text editor via his decade old Amiga, 
struggles through a local 1200 baud Merit server to be further mauled via the 
remote VAX mail servers) is someone elses problem - namely yours.
---------------------------------------------------------------------------
Newsgroups: comp.windows.x.motif
From: daniel@moonshine.osf.org (Daniel Dardailler)
Subject: Re: Font Sizes
Organization: Open Software Foundation, Motif Team
Date: Sat, 2 Jan 1993 19:41:00 GMT

Get the XFontStruct out of a XmFontList  if you're using one.
Than read the Xlib man pages, XTextExtents & XTextWidth sections.
From: straw@cam.nist.gov (Mike_Strawbridge_x3852)
Newsgroups: comp.windows.x.motif
Subject: selecting in ScrolledList causes core dump
Date: 21 Dec 92 15:39:48 GMT
Organization: National Institute of Standards & Technology, Gaithersburg, MD

I am running this on a Sun 4, SunOS 4.1.3, MIT X11R4 and Motif 1.1.

In my application I have a List contained inside a Scrolled Window. The list
has selectionPolicy set to BROWSE_SELECT. Sometimes, but not always, the
following action will cause the application to dump core ...

- Press the select mouse button and drag the cursor off the bottom of the
  list. The list scrolls to the bottom of the list and the last item is
  highlighted. ( i.e. the cursor is now outside of the scrolledList widget 
  and the last item in the list is highlighted).

- Now release the select key.

The application dumps core with the following status from dbx:

  program terminated by signal SEGV (no mapping at the fault address)
  ClickElement() at 0x65e64
  BrowseScroll() at 0x66214
  DoOtherSources() at 0xf778174c
  XtAppNextEvent() at 0xf7781938
  XtAppMainLoop() at 0xf77799cc

Note that it does not crash every time you do this. Most of the time
it calls the XmBrowseSelectionCallback as expected.

Does anyone know what going on here? I don't have Motif source. Is this
a bug in Motif 1.1 or have I forgotten to configure something in the
List/ScrolledWindow combination?

Thanks.

Mike

-----------------------------------------------------------------------
NAME:   Michael Strawbridge             	TELE: (301) 975-3852
USMAIL: National Institute of Standards 	ARPA: straw@cam.nist.gov
		and Technology            	UUCP: uunet!cme-durer!straw
        Rm. B-146, Bldg. 225
        Gaithersburg, MD  20899
Newsgroups: comp.windows.x.motif
From: wells@world.std.com (Chuck Wells)
Subject: Detecting window close on DEC's Alpha Unix workstation
Organization: The World Public Access UNIX, Brookline, MA
Distribution: comp.windows.x.motif
Date: Fri, 1 Jan 1993 16:23:35 GMT

Hello, the FAQ explains a way to detect when a mwm window is closed from
the pulldown menu in its upper left corner.  This works fine on the RS/6000,
running AIX 3.2 (motif 1.1).

However, this no longer works properly on a DEC 3000 (I believe it runs
Motif 1.2).  What happens is that when I close one of my windows, the
entire application immediately exits, and none of my routines get called
to handle the closing of a window.  This also happens if I remove the code
to detect window closings.  In fact, it happens in any and every
application I compile on the computer.  Whether the window is a dialog box
or a shell widget, closing any window kills the entire application.

Does anyone know what the deal is here?  Is it even a Motif issue or did
DEC do something odd with their window manager?

Any help greatly appreciated!  Thanks




-- 
Chuck Wells                               <Insert Generic Quote Here>
wells@world.std.com
From: avinash@felix.contex.com (Avinash Chopde)
Newsgroups: comp.windows.x.motif
Subject: Wcl at exports.lcs.mit.edu - what is WclDoc.t.Z ?
Date: 23 Dec 92 21:06:39 GMT

Looking over the Wcl files at exports, I found a file called
WclDoc.t.Z
It is not a regular PostScript document, nor troff, etc, but does
contain dates that refer to Jan 1993!
Is this work in progress or is it a file meant for current Wcl users?
-- 
---------------------------
Avinash Chopde         office : 617 246 1776x5582
avinash@contex.com     (...!uunet!contex!avinash)
From: mattf@cac.washington.edu (Matthew Freedman)
Newsgroups: comp.windows.x.motif
Subject: Re: Setting Color on OptionMenu Button -- Impossible?
Date: 21 Dec 92 20:43:41 GMT
Organization: U.W. Information Systems

In article <1992Dec17.200759.6766@u.washington.edu>, mattf@cac.washington.edu (Matthew Freedman) writes:
> One obvious thing to do is make the push-button on the option menu the
> same color as all the other push-buttons on the application, which is
> different than the default background. However, OSF in its wisdom made
> the pushbutton a gadget, hence it can not have a different color than
> its parent, which in this case is a rowcolumn. If I set the color of
> that rowcolumn so that the button inherits it, I get a strange looking
> colored border around the button (I.e. the portion of the rowcolumn
> not covered by the button).

Following up my own post here, I found a way to do it. Basically, you
need to get rid of the XmLabel widget (you can always put a separate
one next to the OptionMenu), and shrink the RowColumn so that it is
exactly the same size as the PushButtonGadget, that way it does not
matter if they are both the same color. The following resource
settings are all necessary to get this to work...

  ...XmRowColumn*highlightThickness: 0
  ...XmRowColumn.spacing: 0
  ...XmRowColumn.marginHeight: 0
  ...XmRowColumn.marginWidth: 0
  ...XmRowColumn*XmLabelGadget.marginWidth: 0

The text of the label has to be null. Unmanaging the Label causes
havoc though (at least in 1.1.4).

This still leaves me with a one pixel wide border of the button on the
left side of the button. But it is pretty unnoticeable.

Somebody sent me mail saying that in 1.2 you can simply unmanage the
label, and the row-column will automatically wrap around the button. 

       -- Matt

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
= Matthew M. Freedman                                                 =
= U. of Washington Information Systems       mattf@cac.washington.edu =
= 4545 15th Ave. NE; 4th Floor               (206) 543-5593           =
= Seattle, WA  98105                                                  =
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
From: ray@sbi.com (Raymond Blum (C0140))
Newsgroups: comp.windows.x.motif
Subject: force callback programmatically?
Date: 31 Dec 92 23:00:09 GMT
Reply-To: ray@rann.sbi.com
Organization: Salomon Inc.

Hi Netters! This is my last message of 1992! Before I go, here's what's puzzling me at the dawn of a new year!
  IS there any way to force an event for a particular widget from within a program? I have a text widget whose losingFocusCallback does some verification. I wish to, at one point, do an 'XmTextSetString' for the text widget and then force the losingFocusCallback to be invoked. How do I do the latter?

  Thanks & have a good new year!

---Raymond

------------------------------------------------------------------------
-----                                                              -----
-----                                                              -----
----                  \\\\\\\                                       ----
----                 \\\    \\   People ask me why I'm smiling...   ----
----                  \\ o o             I'm just happy!            ----
----                                                               -----
----                     \_/                                       -----
----                                                               -----
----   Raymond Blum                                                -----
----   ray@rann.sbi.com                                            -----
----   (201) 896-7594                                              -----

Of course these opinions are all mine... whattya think, my EMPLOYER could've thought this stuff up?
From: larry@boris.webo.dg.com (Larry Rogers)
Newsgroups: comp.windows.x.motif
Subject: Re: Centering button in form ?
Date: 22 Dec 92 21:49:41 GMT
Organization: Data General, Westboro, Mass.


Here is an example in Wcl showing the resource values that need to be
set to center a widget, without resizing it, within a form.  There are
alternate solutions in the FAQ.  This one works and is tested with
Motif 1.1.3.

Mri*title: Center that Widget 
Mri.wcChildren:		form

!  Create a form of width and height 200, 200.  This width and height
!  are arbitrary.  Set 'em to whatever you like.

*form.wcClass:    xmFormWidgetClass
*form.wcChildren: push
*form.width: 200
*form.height: 200

; To center the button, set top and left attachment to attach_position
;
; Set top and left position to 50% of form width and height based on
; a fractionBase of 100.
; 
; Set the topOffset to 1/2 the height of the widget
; Set the leftOffset to 1/2 the width of the widget
; Because these are moving the widget negatively WRT center,
;  the values are negative.
;

*push.wcClass:		xmPushButtonWidgetClass
*push.labelString:	Hello World
*push.activateCallback:	WcExitCB()
*push.topAttachment: ATTACH_POSITION
*push.leftAttachment: ATTACH_POSITION
*push.topPosition: 50
*push.leftPosition: 50
*push.recomputeSize: FALSE
*push.width: 120
*push.height: 30
*push.leftOffset: -60
*push.topOffset: -15

--
    @@               Larry Rogers               *
   @@@               Larry_Rogers@dg.com        *   Big Brother
   @@@ &&&           larry@boris.webo.dg.com    *   is Watching
    @@ &&            Data General  508-870-8441 * 

The opinions contained herein are my own, and do not reflect the
opinions of Data General or anyone else, but they should.

"Sometimes we are the windshield, sometimes we are the bug"
   Dire Straits
Newsgroups: comp.windows.x.motif