csbg@its63b.ed.ac.uk (Andie) (12/09/87)
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)jefu@pawl22.pawl.rpi.edu (Jeffrey Putnam) (12/17/87)
In article <821@its63b.ed.ac.uk> csbg@its63b.ed.ac.uk (Bruce) writes: >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 ? 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 (userft4z%rpitsmts@rpitsgw.rpi.edu - at least for now)