Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!uunet!seismo!sundc!newstop!sun!argv
From: argv@turnpike.Eng.Sun.COM (Dan Heller)
Newsgroups: comp.windows.x
Subject: Re: Three XView Questions
Message-ID: <135354@sun.Eng.Sun.COM>
Date: 8 May 90 09:15:48 GMT
References: <24258@mimsy.umd.edu>
Sender: news@sun.Eng.Sun.COM
Distribution: usa
Organization: O'Reilly && Associates
Lines: 60

In article <24258@mimsy.umd.edu> folta@tove.umd.edu (Wayne Folta) writes:
> Could anyone please mail me with any answers to the following problems?
> We are in the midst of moving from SunView to XView, and we have hit
> some snags:
> 
> 1. In SunView, we wrote event procedures so that the buttons in a panel would
>    invert when the user moved the cursor over them. In XView this seems
>    impossible to do...  We can't seem to get LOC_MOVE events in a Panel...

The XView Programmer's manual indirectly addresses this problem.
that is, it tells you how to do what you want to do, but not for the
reasons *you* need it :-)  Read Section 7.17, Panel Event Handling.
This discusses some of the internal mechanisms used by XView to do
this sort of thing.  Also, you should familiarize yourself with
interposing functions (notify_interpose_*).

NOTE: this will make your application non-OPEN LOOK compliant.
It is assumed that if you are using XView, you want to comply
with those user interface specifications.  What you describe
above biolates openlook.

> 2. We have to quickly convert some SunView code to XView that involves
>    the use of pop-up menus. Since XView does not block on menu_show, what
>    is the quick-and-dirtiest way to simulate blocking menus to get this
>    thing up and running. (Unfortunately, it looks like a real bear to tear
>    the code up into action procedures.)

This has to be handled on a case-by-case basis.  I have seen several
scenarios that require everywhere from "no change" to "major change".
I suggest as a general rule of thumb, tho: all the code that follows
a menu_show() function be moved into a new procedure that is a
callback routine from the menu items within the menu being displayed.
The menu_show() should be the last thing executed in the function
from which it was called.  If there are any variables or pointers
that need to be preserved from the original routine for that new
callback routine, attach them to the menu passed to menu_show() via
client data or XV_KEY_DATA.  The callback routine should extract
those variables using xv_get() from the new callback routine.

> 3. In Open Windows 1.0, we have been unable to eliminate the frame menu.
>    The frame menu is now under the control of the window manager, so how
>    (short of NO_DECORATIONS, since we want a window title) can we get
>    rid of the menu or modify it?
You simply can't do this without telling the window manager not to
display the decorations.

> And maybe Sun could add two-dimensional Choice Lists to panels, please?
This isn't sun's decision alone... or rather, it certainly isn't
the XView development team's decision.  While sun certainly has
input on what Open Look provides, ATT has a hand in this as well.
Suffice to say that you are not alone in your desires for changes
to the open look spec to provide for scrollable panels.  I wish I
knew what the procedure was for submitting OPEN LOOK spec changes.
Perhaps someone from sun/att would like to comment on this?

--
dan
----------------------------------------------------
O'Reilly && Associates   argv@sun.com / argv@ora.com
Opinions expressed reflect those of the author only.