HDTenEightyP/NetNews huggingface dataset:
From: rchui@nswc-wo.nswc.navy.mil (Raymond Chui)
Newsgroups: comp.windows.x.motif
Subject: How to make multi-functions in the same callback?
Date: 28 Sep 92 15:23:04 GMT
Organization: Naval Surface Warfare Center - White Oak



	struct {
 	 char   *name;
 	 void   (*func)();
}  command_info[] = {
      "Line",             lines,
      "Circle",           circles,
      "Rectangle",        rectangles,
}

main()
...
...
...
	 sw = XtVaCreateManagedWidget("scrolled_win",
        xmScrolledWindowWidgetClass, form , /* main_w, */
        XmNwidth,                  300,
        XmNscrollingPolicy,        XmAUTOMATIC,
	NULL0;
	
	drawing_a = XtVaCreateManagedWidget("drawing_a",
        xmDrawingAreaWidgetClass, sw,
   	XmNunitType, Xm1000TH_INCHES,
        XmNwidth, 5000,
        XmNheight, 5000,
        NULL);

	XtAddCallback(drawing_a, XmNinputCallback, /* draws */
		command_info[m].func, NULL);

....
....
....
	Why I only get the 1st function "lines" works on drawing_a?
	event I change the value "m", but I never get 2nd and 3rd
	functions "circles" and rectangles" work. How can I make
	multi-functions in the same XtAddCallback? and also allow me
	select the void function?



 --- 
Raymond H. Chui
NSWC U34b
10901 New Hampshire Ave.
Silver Spring, MD 20903-5000
U.S.A.
Voice:1-301-394-5192 Fax:1-301-394-5835
E-Mail:rchui@corona.nswc.navy.mil
 _ __                                  _    ,    __
' )  )                           /    ' )  /    /  ) /
 /--' __. , , ____   ______   __/      /--/    /    /_  . . o
/  \_(_(_(_/_/) ) )_(_) /) )_(_(_     /  ( o  (__/ / /_(_/_(_
          /
         '
	/  / 	/\           \/
       /  /    /  \        ---+---  --] --]
      /  /    /    \          |       |   |
     /  /|   /      \      ---+---    |   |
       / |     --+--          |     \ |  \|
      /  |       |         ---+---  / |  /|
         |    ---+---         |       |   |
         |       |            |       |   |
         |    /  | \          |       |   |
         |   /   |  \        /        |   |
         |      \|          /        \|  \|
From: dansmith@autodesk.com (Daniel Smith)
Newsgroups: comp.windows.x.motif
Subject: losingFocusCallback a bit too effective!
Date: 29 Sep 92 02:18:35 GMT
Distribution: inet
Organization: The Internet


        I'm setting XmNlosingFocusCallback on a TextField.  I'm noticing,
however, that it gets called when I so much as move the pointer off
the dialog.  Well, yeah, that *is* losing focus!  Not what I had in mind.

	What I want to do is detect a button or keypress elsewhere
in the dialog, so that I can verify the textfield before going on.
I can't rely on users hitting the tab key...

	When I look at the cbs->reason field in the callback, it
isn't very helpful, as it doesn't have enough detail.  Going into
the cbs->event, I see that I am getting a FocusOut. 

	I'm just at Volume V, at the FocusIn, FocusOut page, and
am looking at the "detail" field in the event.  Whew.  I'm wondering
if my search is going to low-level land... I think I need to know
when to ignore the FocusOut.  Any ideas (look at the next couple
events after that for a button or keypress?)

				Daniel
From: amga@hpuerca.atl.hp.com (Anne Gale)
Newsgroups: comp.windows.x.motif
Subject: Re: HP ButtonRelease event problem
Date: 29 Sep 92 19:38:25 GMT
Organization: the HP Response Center, Atlanta

/ hpuerca:comp.windows.x.motif / mj@lpi.liant.com (MJ Franzago) /  2:11 pm  Sep 28, 1992 /
I am running Motif 1.1 on an HP 9000/720 and am having problems 
overriding the translation for a ButtonRelease event in a 
DrawingArea widget.  My action routines correctly interpret 
MotionNotify events until a ButtonPress event is incurred.  
Then MotionNotify events are not interpreted until the mouse 
leaves the window and comes back in.  ButtonRelease events 
are *never* incurred.

My test program (which is included) works fine on a Sun/4, also
running Motif 1.1.  Has anyone seen this problem on the HP
and if so, is there a workaround?

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

I had a customer several months back who reported the identical 
problem to me.  I filed a problem report, and found that the
best workaround was to replace the translation table resource for
the drawingAreaWidget.  To help figure out the exact translation
table in effect for a given widget, you might try the undocumented
Intrinsics function "XtDisplayTranslations".  Use this as an action
in a translation table, and when the associated event fires, the
entire translation table for the widget will be printed on stdout.

In the meantime, my bug report has gone off to the lab where they
responded that this is not a bug, but indeed is functioning as
expected.  The lab responded as follows:


  In Appendix B (Translation Table Syntax) of the X Toolkit Intrinsics
  manual, it states:

	"In particular, pointer motion and double-click translations
	cannot coexist in the same translation table."

  Since button1 has a double-click translation associated with it, after
  pushing it and releasing it, it waits for the second click.  Only
  another event (ie pushing another button or leaving the window) will it
  stop this waiting and resume capturing the motion events.

  So when you replace the existing translations with your translations
  (which don't have the offending double-click translation), the program
  works as expected.  Another way to work around this would be to just
  remove the double-click translation and leave the others in place.


Hope this helps.
Anne Gale
HP Response Center
From: veym@cernvm.cern.ch (Marc Vanden Eynden)
Newsgroups: comp.windows.x.motif
Subject: pushbuttons reacting on input focus ?
Date: 6 Oct 92 08:24:37 GMT
Distribution: comp
Organization: CERN

Hi,
A lot of our clients ask for pushbuttons which reverse their colors (bg /fg)
when the cursor is moved on it. This without having to press any mouse key.
This is particulary useful to detect immediately the active zones of an 
interface without having to click on the button. As pushbuttons react only on
arm, activate and disarm callbacks, does anybody have a good idea how this
implement this additional feature bearing in mind that we have hundreds of
applications to write ???
Thanks a lot for your collaboration.

M.Vanden Eynden
CERN - European laboratory for particles physics
CH 1211 - geneva 23.
email : veym@cernvm.cern.ch
Newsgroups: comp.windows.x.motif
From: rad2r@uvacs.cs.Virginia.EDU (Robert DeLine)
Subject: Simple MWM question
Organization: University of Virginia Computer Science Department
Date: Tue, 29 Sep 1992 05:07:25 GMT

Sorry to bother the net with such a simple question, but I've tried
all our local sources of information.

I've been using an icon box with MWM and really like it.  The only
thing I don't like is that, whenever the box is full and MWM
therefore causes my icon box to scroll, it chooses to scroll
horizontally.  (In other words, it adds the new icons to the right
of the icons already present.)  I'd prefer to scroll vertically. 
(In other words, I'd like it to add the new icons below the icons
already present.)

My guess is that this can be done by setting the right magic X
default.  I've empirically discovered this default has nothing to do
with iconAutoPlace or iconPlacement (unless I'm using them
incorrectly).

Any help?  (Email prefered.)

Thanks a bunch,

Rob DeLine
Computer Science, University of Virginia
deline@Virginia.EDU
From: rik@csc.liv.ac.uk (Rik Turnbull)
Newsgroups: comp.windows.x.motif
Subject: XmScale
Date: 28 Sep 92 12:40:37 GMT
Organization: Computer Science, Liverpool University

Help!!

I am trying to implement something similar to the
Motif XmScale widget. However instead of using the
slider I want to use a colour bar to represent the
current position ie. the bar will grow and shrink in
size rather than having a single sized slider (is that
clear? probably not! :-) )

Any help appreciated...

Rik.
From: ls@inf.rl.ac.uk (Lakshmi Sastry)
Newsgroups: comp.windows.x.motif
Subject: Address for OSF in Europe
Date: 28 Sep 92 13:51:26 GMT
Organization: Rutherford Appleton Laboratory, Informatics Department, U.K.


Hello folks!

Ever since I read about the availability of OSF/Motif Version 1.2, I have been trying to reach their sales
department without much success (There was no response to my fax.).

Is there an European distribution outlet for OSF/Motif Version 1.2? If so could you please email me
the address and contact name? 

Many thanks in advance.

Lakshmi Sastry
Visualisation Group,
Informatics Department,
Rutherford Appleton Laboratory,
Chilton, Didcot, Oxfordshire, UK.
OX11 0QX

Fax:+44 235 445831
email: ls@inf.rl.ac.uk
Newsgroups: comp.windows.x.motif
From: deveau@oceanroutes.ns.ca ("Terry J. Deveau")
Newsgroups: comp.windows.x.motif
Subject: Re: Push buttons
Date: 1 Oct 92 18:57:38 GMT
Distribution: inet
Organization: Oceanroutes Canada Inc.

Sougata Mukherjea <sougata@cc.gatech.edu> writes:
> Is it possible to invoke different programs when a push button is clicked 
> depending on whether the right or the left mouse button is used?  

Yes.  The easiest way I know of doing it is to install your own
translation on the right button (the left button will invoke the
XmNactivateCallback by default).  You can make the action for the
right button ArmAndActivate() (same as the left button), and then
in the callback function, declare the third argument to be:

XmAnyCallbackStruct *cbs;

and check which button was pressed as follows:

if (cbs->event->xbutton.state & Button1Mask) { left button was used }
if (cbs->event->xbutton.state & Button3Mask) { right button was used }

If both buttons were used together, both blocks will be executed;
if you don't want that to happen, change "&" to "==" in the two
lines above.  Anyway, you get the idea. ... Terry
From: 6500msd@ucsbuxa.ucsb.edu (Michael D'Errico)
Newsgroups: comp.windows.x.motif
Subject: Re: Q: File Selection Box (is it retarded or am I?)
Date: 4 Oct 92 04:23:14 GMT

In article <1992Oct2.171826.12975@news.media.mit.edu> dyoung@media.mit.edu (David Young) writes:

>if you move into a directory which only has sub-directories and no files,
>then the bottom area is EMPTY!!!  If you want to create a new file, you
>need to copy the current path from the Filter area at the top, and then
>type in the name of the file you want to create.  This seems really
>retarded. 

You don't need to type the current path if you want to create a file
in the current directory.  The XmFileSelectionBoxCallbackStruct (sigh)
contains information on the current directory so all you need to do
is type the name of the file.  Below is a callback routine that will
do the job:

  void saveFile(w,client_data,call_data)
    Widget w;
    caddr_t client_data;
    XmFileSelectionBoxCallbackStruct *call_data;
    {
    FILE *fp;
    char *path;
    char *file;
    char *file2save;

    XmStringGetLtoR(call_data->value,XmSTRING_DEFAULT_CHARSET,&file);
    if (fileHasPath(file)) /*function to check for '/' in file*/
      file2save = file;
    else  {
      XmStringGetLtoR(call_data->dir,XmSTRING_DEFAULT_CHARSET,&path);
      file2save = (char *)malloc((size_t)(strlen(path)+strlen(file)+1));
      strcpy(file2save,path);
      strcat(file2save,file);
      free(path);
      free(file);
      }

    fprintf(stderr,"saving %s\n",file2save);
    if (!(fp = fopen(file2save,"w")))
      fprintf(stderr,"ERROR: couldn't create %s\n",file2save);
    else  {
      if (fwrite(&data2save,sizeof(data_type),num_data,fp) != num_data)
        fprintf(stderr,"ERROR: problem writing %s\n",file2save);
      fclose(fp);
      }
    free(file2save);
    }


Michael D'Errico

From: jconrad@hpdmd48.boi.hp.com (Jim Conrad)
Date: Thu, 1 Oct 1992 15:48:54 GMT
Subject: Looking for Example of XmNmessageWindow
Organization: Hewlett Packard - Boise, ID
Newsgroups: comp.windows.x.motif

Does anyone know where I can find an example of a successful use of the
XmMainWindow's XmNmessageWindow resource?  I've bound the message window
to my main window by hand (XmMainWindowSetAreas apparently can't do it)
but have never succeeded in getting its contents displayed.

Jim Conrad
jconrad@hpbs1904.boi.hp.com
Newsgroups: comp.windows.x.motif
From: lms@rle-vlsi.mit.edu (Luis Miguel Silveira)
Subject: Question on mwm decorations (and epoch)
Organization: Research Laboratory of Electronics, Massachusetts Institute of
	Technology
Date: Sun, 27 Sep 1992 06:48:10 GMT



I have a question about client decorations on mwm.  I could not see an
answer for this in the FAQ, so...

The FAW says that in order to change the decorations on clients under
Mwm one should use (for instance on xbiff):

        Mwm*XBiff*clientDecoration:     <whatever>

What I actually want is to change the decoration of the epoch
minibuffer (just the minibuffer, *not* the epoch windows).

Any help will be appreciated.  Please reply by e-mail as I do not read
this mewsgroup very frequently.

Thank you.

-Miguel


--
=============================================================================
Luis Miguel Silveira                            e-mail : lms@rle-vlsi.mit.edu
=============================================================================
Research Laboratory for Electronics  -  Massachusetts Institute of Technology
Room 36-893, 77 Massachusetts Ave,                      Phone: (617)-253-7307
Cambridge MA 02139                                      Fax:   (617)-258-7864
=============================================================================
also affiliated with:
INESC - Instituto de Engenharia de Sistemas e Computadores
Av. Alves Redol, 9-3o, 1000 Lisboa, PORTUGAL           Phone: (351)-1-3100288
=============================================================================
From: amga@hpuerca.atl.hp.com (Anne Gale)
Date: Wed, 30 Sep 1992 20:21:07 GMT
Subject: Re: HP and motif version
Organization: the HP Response Center, Atlanta
Newsgroups: comp.windows.x.motif

/ hpuerca:comp.windows.x.motif / mark@BHANU.ANDYNE.ON.CA (Mark Levison) /  2:29 pm  Sep 23, 1992 /

Could anyone tell me what version of Motif HP is currently shipping on
their machines I expect to get one in the next few weeks and want to know
what to expect.

Cheers
Mark Levison
mark@bahnu.andyne.on.ca
----------


HP's product, Motif 1.1, is OSF/Motif 1.1.3 -- almost. OSF's product has a
few bug fixes that HP's doesn't & HP's product has a few "enhancements"
that aren't in 1.1.3.

This lack of release synchronization has caused confusion and
frustration among lots of HP's customers. As of Motif 1.2, we can
expect to see code which is the same as OSF's comparable release.


Hope this helps,
Anne Gale
From: deveau@oceanroutes.ns.ca ("Terry J. Deveau")
Newsgroups: comp.windows.x.motif
Subject: Re: How to get back dialogbox automatically?
Date: 29 Sep 92 18:47:30 GMT
Distribution: inet
Organization: Oceanroutes Canada Inc.

> I have a trivial problem. I have a dialog box to let the user
> select some action, and execute the action. All I want is, once
> I finish executing the action taken, how do I get back to my
> dialog box? I would like the dialog box to pop up automatically
> with the highlight bar on the last selected position and really 
> quit with the quit button only.
> 
You can stop the dialog from being automatically unmanaged by setting
XmNautoUnmange to False.  The resource is defined for all widgets
which are a subclass of XmBulletinBoard.  You will have to explicitly
unmange the dialog in you quit callback. ... Terry

Newsgroups: comp.windows.x.motif
From: kingo@bnr.ca (Kiem Ngo)
Subject: Re: How to strip off "_popup" string in XmCreateFormDialog?
Keywords: _popup string XmCreateFormDialog
Reply-To: kingo@bnr.ca
Organization: Bell-Northern Research
Date: Thu, 1 Oct 1992 12:36:16 GMT

In article <i81XRB1w165w@tmchome.UUCP>, tchal@tmchome.UUCP (Thomas M. Chalfant) writes:
|> dwu@hal.gnu.ai.mit.edu (Daniel Wu) writes:
|> 
|> > 
|> > In my code, I call the routine:
|> > 
|> >       configDialog = XmCreateFormDialog (dialogShell,
|> > 		"Printer/Plotter Setup", NULL, 0);
|> > 
|> > The resulting dialog box has the Menu title:
|> > 
|> > 		Printer/Plotter Setup_popup
|> > 				     ^^^^^^^
|> > I want the string to simply read:
|> > 
|> > 		Printer/Plotter Setup
|> > 
|> > without the "_popup" appendage.
|> > 
|> > Can someone tell me what I have to do to accomplish this?
|> 
|> First Daniel, I wonder if the dialogShell widget you are passing in as
|> the first parameter (parent) really is a Dialog Shell?  If it is then
|> you probably do not want to be calling XmCreateFormDialog() but rather
|> XmCreateForm().  The ...Dialog() version of the convenience creation
|> functions creates the dialog shell for you already.  Anyway, assuming
|> all is as what you want, on to your answer:
|>     ...
|>     String title = "Printer/Plotter Setup";
|>     ...
|>     configDialog = XmCreateFormDialog (dialogShell, title, NULL, 0);
|>     XtVaSetValues(XtParent(configDialog), XmNtitle, title, NULL);
|>     ...
|> 
|> This should do the trick for you.  You just have to make sure you are
|> setting the XmNtitle resource on the dialog shell!
|> 
|> Tom
It does not matter what kind of dialogs is: you can set the
title name to anything you want with one X call:
     XStoreName(XtDisplay(toplevel), XtWindow(XtParent(motif_dialog_widgetID)), dialog_title);
-- 

============================================================================
These are not necessarily the opinions of BNR.
,------.--------------.---------------------,
| Kiem |   e-mail:    | Fax: 1-613-765-4018 |  "All work and no play makes
|  Ngo | kingo@bnr.ca | Ph:  1-613-765-4774 |       Jack a dull boy --
`------'--------------'---------------------'   and Jill a wealthy window."
      Bell Northern Reseach Ltd.                                - Evan Esar
       Ottawa, Ontario Canada.
============================================================================
From: harris@cezanne.cs.unc.edu (Trey Harris)
Newsgroups: comp.windows.x.motif
Subject: Graphical front end for motif customization?
Date: 27 Sep 92 19:15:01 GMT
Organization: The University of North Carolina at Chapel Hill

I hope I won't be eaten alive for saying such a thing, but I simply
don't have the time (at least until summer) to learn about the
customization opetions available in my environment.

What I would like is a graphical (or even text-based, for that matter)
front-end to do my .Xdefault, .X11R4startup, etc. customization.  I
would like a simple list of common options that I can check or uncheck
(a la the Mac's control panels) and then have the program edit my
setup files for me.

Does such a thing exist?  If so, is there an ftp site where I can get
it?

Thanks in advance.
Trey Harris
--Stranger in a Strange Thread!
From: jones@colisd.COLONIAL.COM (Libby Jones)
Newsgroups: comp.windows.x.motif
Subject: window manager freeze up
Date: 25 Sep 92 15:17:28 GMT
Reply-To: jones@colisd.UUCP ()
Organization: Colonial Management, Boston


hello netters,

We have DECstation 3100's running Ultrix 4.2 and motif 1.1.1.  We 
are having problems with the mwm freezing up.  This happens pretty
regularly.  The keyboard and mouse clicks ar not recognized.  All of
the windows are "frozen".  When we log into another machine and connect
to the frozen machine via telnet, and kill the window manager, and 
restart the window manager, everything is A-ok.  Does anyone
have a solution?  Does any one have any suggestions as to how to
detect the problem?  If we could detect the problem, we could write
a little program that runs in the background looking for the freezeup
and performing the appropriate actions when the freezeup is detected.
We tried doing this with XmIsMotifWMRunning().  This function
seems to think the window manager is running, even though it is frozen.
When you look at the process table the mwm is there and looks ok.

				Thank you VERY much,

					Libby Jones + Pete Hill

Newsgroups: comp.windows.x.motif
From: achan@idaho.tdd.sj.nec.com (Amy Chan)
Subject: Re: Large Option Menus
Organization: NEC-AM TDD, San Jose, California
Date: Wed, 30 Sep 1992 16:35:26 GMT

In article <LsPTRB1w165w@bluemoon.rn.com> rogerg@bluemoon.rn.com (Roger Grywalski) writes:
>Does anyone know how Motif 1.1 is supposed to deal with option menus
>where the options cannot all fit on the screen.  ie there are too
>many options.  Is there a way to scroll the options?  Any help would
>be greatly appreciated.

I don't think there is a way to scroll the options in an option menu.
May be a list widget is more appropriate in this case?

Amy
--
Amy Chan                 | E-Mail:
NEC America              |  INET: achan@tdd.sj.nec.com
110 Rio Robles           |  UUCP: ...{decwrl,oliveb}!necsun!achan
San Jose, CA 95134       |
From: aking@elm.Berkeley.EDU (Andy King)
Newsgroups: comp.windows.x.motif
Subject: Loss of focus - help needed
Date: 2 Oct 92 16:53:56 GMT
Reply-To: aking@trees.az05.bull.com (Andy King)
Organization: Bull HN Inc.

I am having a problem with loss of focus in a Motif application.  I
am using X11R4 and Motif 1.1 on an HP 700.  The program has a
standard menu bar, along with a rowcolumn which contains a number
of text widgets.  On entry to the program, the focus is set by
Motif to the first text widget, indicated by both the caret and the
border highlight.  If the user pulls down a menu entry, but does not
select anything, the focus (indicated by a border) disappears from
the text widget, and does not reappear, even though the menu has been
cancelled.  The only way to regain any focus on the text widgets is
to explicitly set focus to another application, or to bring up a
dialog in the current application.

I have spent a few hours trying to find the cause of this problem.
The focusPolicy and keyboardFocusPolicy are both set to explicit.  If
I set the keyboardFocusPolicy to pointer, and focusAutoRaise to True,
the focus works correctly - but this is not acceptable, since explicit
focus is a requirement for the users.  I have tried forcing the focus,
using the method described in the FAQ (setting a timeout callback and
doing a TRAVERSE_CURRENT in the callback), but to no avail.

I'm not sure that there is sufficient information here to speculate on
the cause of this problem, but I would really appreciate any
suggestions!

While on the subject of focus, I'm sure that some of you have noticed
a recurring theme concerning the issue of forcing focus within an
application.  This is usually required when the programmer wants to
force the user to make a valid entry in a text widget prior to changing
focus.  The normal response to this issue is "don't do it - it's against
the style/principles of the X/Motif paradigm".  But what's the
alternative?  You can validate entries when 'save' is activated, but
what if a mistake which, if the user had been notified, the notification
could have prevented wasteful subsequent errors.  For example, the user
is entering out of range values in each text widget, which could have
been prevented if they'd been told about the error in the first entry.

So what should be done?  Forcing the focus to stay on the erroneous
entry is not a Good Thing, and is discouraged.  But an error dialog
which doesn't prevent loss of focus will only mean that the user has to
reset focus to the entry in error before correcting it - so they have
to find the entry (granted, it can be highlighted as part of the error
process), and move to the mouse, or back tab to it (control-shift-tab?!).

What's the solution ... does anyone at OSF have a suggestion?  Why
can't you just let me, the programmer, control focus.  I promise not to
overuse or abuse it - I certainly don't want to turn the whole
interface into an old-style fill in the blanks forms application, but
I do want to help the user not to waste time ...

Many thanks,

Andy King     aking@trees.az05.bull.com
Newsgroups: comp.windows.x.motif