Path: utzoo!mnetor!uunet!husc6!bbn!uwmcsd1!leah!itsgw!imagine!pawl22.pawl.rpi.edu!jefu From: jefu@pawl22.pawl.rpi.edu (Jeffrey Putnam) Newsgroups: comp.windows.news Subject: Re: Windows and menus through the CPS interface Message-ID: <149@imagine.PAWL.RPI.EDU> Date: 16 Dec 87 16:11:47 GMT References: <821@its63b.ed.ac.uk> Sender: news@imagine.PAWL.RPI.EDU Reply-To: userft4z%rpitsmts@rpitsgw.rpi.edu Organization: RPI Public Access Workstation Lab - Troy, NY Lines: 53 Keywords: NeWS windowing, menus, CPS interface 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)