Subject: Windows and menus through the CPS interface

From: [email-masked] (Andie)
Date: Tue, 15 Dec 87 11:47:54 EST

Hi everybody !

I'm a final year student at Edinburgh University and as part of my final
year project I am using NeWS to build up a document composition system.
Alas, I'm new to NeWS and the NeWS manual does seem to be rather sketchy,
especially when it comes to using the CPS interface.

Having had a look at the stuff that is floating around in this newsgroup
I think that someone out there will be able to help me.

Point 1 : How can I control the litewin.ps and litemenu.ps packages through
          the CPS interface - especially, how do I get notification to the
          C program that something is happening ?

Point 2 : This may be trivial, but when I create an overlay for the purposes
          of rubber-banding, using the getclick family of operators, I can
          never get the overlay to disappear again. What is happening and
          how should it be done ?

If these points have already been raised in the past then I will be happy to
receive direct e-mail from anybody who can answer any part of the above
queries.

As they say: When the going gets tough, I get the hell out of it !

Bruce Gilmour (CS4 student at Edinburgh University)

---

From: [email-masked] (Jeffrey Putnam)
Date: Wed, 16 Dec 87 23:00:24 EST

>          C program that something is happening ?

Menus are easy to handle as the notification may be done through the
menu selection action - thus, you just have the particular entry have
an action that does the appropriate printing so that cps can grab it
(i forget the exact syntax or i would include an example).

The other question, about litewin.ps, is more interesting and points up
a nice feature of the lite* interfaces.  If you want to have, say, a window
notify the applications program that it has changed size, or become iconic,
or whatever, you can easily override the code used for that method.
There are two ways to do this, first by creating an instance of the object
and redefining the methods of interest in that particular instance by
sending the instance a message that looks (roughly) like:
{
  \MethodToChange { ... } def
} Instance send
(note that there is some sort of method described in the manual that
will enable you to grab the old code for that method in the new method
if that is needed - again, i forget the name and syntax).

The second way to handle this is to build a new class that inherits
from the old class and then to redefine the methods of interest in the
new class.  You can still get at the old methods using "super send".

Code looks something like:
/NewClass OldClass
dictbegin
   % new instance vars
dictend
classbegin
  /Method
  {
     3 copy % copy args if needed.
    % new stuff can go here.  I do a n copy to save the
    % args the super method will need.
     /Method super send
    % new stuff goes here too, remember that someone may
    % depend on the return value(s) so it should be left
    % on the stack appropriately
  } def
classend def

Hope this helps.

jefu ([email-masked] - at least for now)