guineau@wjg.enet.dec.com (W. John Guineau) (01/25/91)
In article <1991Jan25.075446.716@Neon.Stanford.EDU>, torrie@cs.stanford.edu (Evan J Torrie) writes: |> From: torrie@cs.stanford.edu (Evan J Torrie) |> Newsgroups: comp.sys.amiga.advocacy |> Subject: Re: Hooks into the OS vs doing it all yourself (Was Re: |> Clueless Mac<>) |> |> peter@sugar.hackercorp.com (Peter da Silva) writes: |> |> >In article <1991Jan21.172643.20642@Neon.Stanford.EDU>, |> torrie@cs.stanford.edu (Evan J Torrie) writes: |> >> lrg7030@uxa.cso.uiuc.edu (Loren J. Rittle) writes: |> >> >most things under the MacOS, if you want it *you*, the |> programmer, |> >> >must recreate it for every program. |> |> >> Hmm. I just use a class library for most of the "common" |> actions. |> >> Takes no work at all on my part. |> |> >This is the X-windows solution. Let's load up every program with |> extra baggage |> >because the GUI/OS/whatever is inadequate. And the Mac doesn't even |> have |> >shared libraries to make this relatively painless. |> |> What kind of hooks does the Amiga have into the OS for things that |> are handled "automagically"? e.g. I recall that when a window gets |> resized, the OS handles everything for you [mouse tracking? window |> outline? new window frame?] and just sends you a "Window Changed" |> message. |> Can your program get its hooks into this event BEFORE the OS gets |> hold of it and "do its own thing"? These windows are called SMART_REFRESH, if you want to do it yourself, you tell the OS (when you create a window) that you will handle refresh events. Then you get BEGIN_REFRESH messages (or something to the effect of "it's time to fix your window") |> |> -- |> ------------------------------------------------------------------------ ------- |> Evan Torrie. Stanford University, Class of 199? |> torrie@cs.stanford.edu |> "If it weren't for your gumboots, where would you be? You'd be in |> the |> hospital, or in-firm-ary..." F. Dagg |> -- W. John Guineau grep meaning life | more Digital Equipment Corporation guineau@wjg.enet.dec.com or wjg@wpi.wpi.edu
peter@sugar.hackercorp.com (Peter da Silva) (01/30/91)
In article <1991Jan25.075446.716@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: > What kind of hooks does the Amiga have into the OS for things that > are handled "automagically"? e.g. I recall that when a window gets > resized, the OS handles everything for you [mouse tracking? window > outline? new window frame?] and just sends you a "Window Changed" > message. Yep. > Can your program get its hooks into this event BEFORE the OS gets > hold of it and "do its own thing"? Nope. You can tell Intuition the bounds you're willing to let the user manage the window within, but that's it. > Also, what exactly happens with scrollbars? (sorry for my > preoccupation with scrollbars, but they're interesting things :-) ) > When you click and hold down on a scroll arrow, how does the OS "know" > when you've scrolled to the end of a document? Amiga scrollbars (proportional gadgets) don't have arrows. If you see an arrow the application is managing two gadgets together. But if you want to know how Intuition (which, by the way, is not the O/S, it's just another task) knows how far you can frag a scrollbar with the mouse, I can tell you that: the application tells it how far it can move the knob. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
torrie@cs.stanford.edu (Evan J Torrie) (01/31/91)
peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1991Jan25.075446.716@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: >> What kind of hooks does the Amiga have into the OS for things that >> are handled "automagically"? e.g. I recall that when a window gets >> resized, the OS handles everything for you [mouse tracking? window >> outline? new window frame?] and just sends you a "Window Changed" >> message. >Yep. >> Can your program get its hooks into this event BEFORE the OS gets >> hold of it and "do its own thing"? >Nope. You can tell Intuition the bounds you're willing to let the user manage >the window within, but that's it. Well this will probably cause some flames, but this is an example of where the Mac is MORE customizable than the Amiga... i.e. where the user can make things work the way he wants, not the way the OS wants. I am reminded of a quote in Steve Chernicoff's Macintosh Revealed book... paraphrasing, he said something like "When Apple released the Macintosh 128K, critics pounded it for being a closed system. While their criticisms of the hardware were well-founded, what they didn't realise was that the Macintosh had an almost completely open software design". For example, all the hooks into window definition functions, menu definition functions, etc... where you can roll your own code, and make your own windows/menus etc... this is how the Mac gets all those nice NeXT/Motif type windows without having to rewrite existing program code. While it means you may have to write more code to handle the general case, it gives you more control over the final result as well. >Amiga scrollbars (proportional gadgets) don't have arrows. If you see an arrow >the application is managing two gadgets together. But if you want to know how >Intuition (which, by the way, is not the O/S, it's just another task) knows how >far you can frag a scrollbar with the mouse, I can tell you that: the >application tells it how far it can move the knob. Can you have callback functions.. i.e. get Intuition to call your function while it's moving the knob? -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu Today's maxim: All socialists are failed capitalists
djohnson@beowulf.ucsd.edu (Darin Johnson) (01/31/91)
In article <1991Jan31.011702.12095@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: >peter@sugar.hackercorp.com (Peter da Silva) writes: > >>In article <1991Jan25.075446.716@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: >>> Can your program get its hooks into this event BEFORE the OS gets >>> hold of it and "do its own thing"? > >>Nope. You can tell Intuition the bounds you're willing to let the user manage >>the window within, but that's it. > > Well this will probably cause some flames, but this is an example of >where the Mac is MORE customizable than the Amiga... i.e. where the >user can make things work the way he wants, not the way the OS wants. OK, the answer given is probably misleading... The user CAN(!) tell the OS to do nothing at all with the window - and the program is responsible for redrawing, etc. This is much the same way the Mac does it - so the Mac is not more customizable in this sense. However, the common case on the Amiga is to let the OS handle redrawing, which it does by saving occluded portions of the window in memory. This takes extra memory, but allows the programmer to not have to worry about this. So there are no "approved" hooks into the OS, but you can still handle your own drawing functions. This leaves out the possibility of having the OS redraw the scrollbars, etc, while the program handles redrawing of its own graphics. (actually, you could probably use 2 windows or layers to do this...) Unapproved hooks are possible by letting the program peek into the global input stream before Intuition sees it... -- Darin Johnson djohnson@ucsd.edu - Political correctness is Turing undecidable.
rjc@geech.ai.mit.edu (Ray Cromwell) (01/31/91)
In article <1991Jan31.011702.12095@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: >peter@sugar.hackercorp.com (Peter da Silva) writes: > >>In article <1991Jan25.075446.716@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: >>> Can your program get its hooks into this event BEFORE the OS gets >>> hold of it and "do its own thing"? > >>Nope. You can tell Intuition the bounds you're willing to let the user manage >>the window within, but that's it. > > Well this will probably cause some flames, but this is an example of >where the Mac is MORE customizable than the Amiga... i.e. where the >user can make things work the way he wants, not the way the OS wants. > I am reminded of a quote in Steve Chernicoff's Macintosh Revealed >book... paraphrasing, he said something like "When Apple released the >Macintosh 128K, critics pounded it for being a closed system. While >their criticisms of the hardware were well-founded, what they didn't >realise was that the Macintosh had an almost completely open software >design". > For example, all the hooks into window definition functions, menu >definition functions, etc... where you can roll your own code, and >make your own windows/menus etc... this is how the Mac gets all those >nice NeXT/Motif type windows without having to rewrite existing >program code. Well the Amiga can do this too, but its not officially supported. Programs can use input handlers to get mouse/key events before intuition gets them, programs can SetFunction() OpenWindow, programs can open their own screen and uses layer's to implement their own windowing system. There are many ways to customize the interface. For instance, there are programs like Exploding Windows, PopUpMenu, Snap, NewLook, NeXTWindows that do a good job of enhancing the Amiga's look. In the area of enhancing the Amiga's environment, users can choose from a wide variety of Shells, Replacement Workbenchs, Mouse Accelerators, Pointer Animators, Screen blankers, Clocks, Gadget Replacements, Screen hacks, input handlers, etc. Look at the Fish collection, over 400 megabytes of Freeware, and atleast 6-10% of it is in the format of user enhancements. > While it means you may have to write more code to handle the general >case, it gives you more control over the final result as well. > >>Amiga scrollbars (proportional gadgets) don't have arrows. If you see an arrow >>the application is managing two gadgets together. But if you want to know how >>Intuition (which, by the way, is not the O/S, it's just another task) knows how >>far you can frag a scrollbar with the mouse, I can tell you that: the >>application tells it how far it can move the knob. > > Can you have callback functions.. i.e. get Intuition to call your >function while it's moving the knob? Not that I know of. I wouldn't want it. Consider a heavy loaded system with the user causing lots of input events. Your call-back function better be damn FAST or your going to suck up lots of CPU. Instead, the Amiga sends messages and you can service these messages at your own leisure, a benefit is that calls to Wait()/GetMsg() can yield the CPU to other tasks while your waiting for a message. If you want the OS to call your functions, install an input handler and have it parse a list and call the appropriate functions, or spawn a task to Wait for messages, and have that task translate those messages into calls to other tasks. Hard? No. Not as easy as call back, but any fairly good Amiga programmer can emulate them with an input handler in a few hours. My question would be, why? I like the message system better. Also, some of the graphics.library functions are call-back (the animation and collision routines) Since when does the Mac have a NeXT/Motif look? If so, is it a PD hack and where can I get it? I want to try it on my friends Amax. I think plain old finder looks horrible, and so do many of the Mac requestors. AmigaDOS 2.0 makes the Mac look like C64 GEOS. >-- >------------------------------------------------------------------------------ >Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu >Today's maxim: All socialists are failed capitalists
es1@cunixb.cc.columbia.edu (Ethan Solomita) (01/31/91)
In article <1991Jan31.011702.12095@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: >peter@sugar.hackercorp.com (Peter da Silva) writes: > >>In article <1991Jan25.075446.716@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: >>> Can your program get its hooks into this event BEFORE the OS gets >>> hold of it and "do its own thing"? > >>Nope. You can tell Intuition the bounds you're willing to let the user manage >>the window within, but that's it. To quote from the RKM Libs&Devs (Blue) page 165, referring to IDCMP flags: SIZEVERIFY "You set this flag if your program is drawing to the window in such a way that the drawing must be finished before the user sizes the window. If the user tries to size the window, a message is sent to the application and Intuition will Wait() until the program replies. ..." > > Well this will probably cause some flames, but this is an example of >where the Mac is MORE customizable than the Amiga... i.e. where the >user can make things work the way he wants, not the way the OS wants. Not in this case, I'm afraid. > For example, all the hooks into window definition functions, menu >definition functions, etc... where you can roll your own code, and >make your own windows/menus etc... this is how the Mac gets all those >nice NeXT/Motif type windows without having to rewrite existing >program code. I'm not sure what you mean, but there are more than enough flags in creating Amiga windows. I've never seen a Mac window look like anything besides a Mac Finder window, so I guess that's not what you're talking about. And on the Amiga you can replace any system function with one of your own writing (affecting the system globally), which (I believe) can also call the original function as well. This has been put to good use by replacing the DisplayBeep() function, used to flash the background when there is an error. The program made it play some digitized sound instead. The was also ew, Exploding Windows, which would do like a Mac and show the window growing to full size by intercepting I assume OpenWindow and CloseWindow. >>Amiga scrollbars (proportional gadgets) don't have arrows. If you see an arrow >>the application is managing two gadgets together. But if you want to know how >>Intuition (which, by the way, is not the O/S, it's just another task) knows how >>far you can frag a scrollbar with the mouse, I can tell you that: the >>application tells it how far it can move the knob. > > Can you have callback functions.. i.e. get Intuition to call your >function while it's moving the knob? > From the RKM page 164 GADGETDOWN Your program will receive a message of this class when the user selects a gadget that was created with the GADGIMMEDIATE flag set. GADGETUP When the user releases a gadget that was created with the flag RELVERIFY set, your program will receive a message of this class. >-- >------------------------------------------------------------------------------ >Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu >Today's maxim: All socialists are failed capitalists -- Ethan "It seemed like he appeared on every television show except Wheel of Fortune. You see, he was afraid that Vanna might turn over the 'L' word." -- George Bush attacking Michael Dukakis for going on TV
kent@swrinde.nde.swri.edu (Kent D. Polk) (01/31/91)
In article <1991Jan31.044116.25645@mintaka.lcs.mit.edu> rjc@geech.ai.mit.edu (Ray Cromwell) writes: >In article <1991Jan31.011702.12095@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: >> >> Can you have callback functions.. i.e. get Intuition to call your >>function while it's moving the knob? > [...] >calls to other tasks. Hard? No. Not as easy as call back, but any >fairly good Amiga programmer can emulate them with an input handler >in a few hours. My question would be, why? I like the message system >better. I like the current messaging system better than callbacks also. It does provide more control over the situation, though callbacks certainly offer a simpler mechanism. As to tracking a moving knob, that's now a cinch with GadTools, and it doesn't take a few hours anymore. More like about 5 minutes from the time you finish reading the documentation. Unsolicited Testimonial: I now can knock out a complete gadget interface for one of my filter processes in an afternoon instead of a couple of days like it used to take - even with PowerWindows (always wasted an afternoon changing the PowerWindows source file). Just about every aspect of handling simple gadgets has been made almost trivial since I started using GadTools. I can now: - Programatically create gadgets based on a variety of parameters (simply too much trouble before GadTools). - Ghost and link gadgets through a simple GT_SetGadgetAttrs() call to the specified gadgets. - Modify groups of related gadgets to represent, say, an array of structures where the array element is defined by a cycle gadget - extremely easily. I won't even bother to explain how easy it is to deal with sliders now. Yep, I can even track those sliders while I have > 65 tasks, including 23 CLI processes running. It's a busy machine, and I can still edit source code and 'rn' while all this is going on. The short of it is that now my multi-process, multi-sample, event-oriented data acquisition system (phew!) now has window/gadget interfaces for many of the processes, with more to come. Thanks Peter, et al. ------------------------------------------------- BTW, Kim DeVaughn, while updating Sksh, can you please remove the 20 CLI limit on the process status listing? (How are things going?) Thanks Kent Polk: Southwest Research Institute (512) 522-2882 Internet : kent@swrinde.nde.swri.edu UUCP : $ {cs.utexas.edu, gatech!petro, sun!texsun}!swrinde!kent
navas@cory.Berkeley.EDU (David C. Navas) (02/01/91)
In article <1991Jan31.011702.12095@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: > Can you have callback functions.. i.e. get Intuition to call your >function while it's moving the knob? A) Intuition sends a message to your task every time the knob is moved. B) You can use boopsi in 2.0 to have your functions (or even other objects) called while you are dragging the knob. eg. You can build an object which has a pre-defined scrollbar which auto-magically calls a text-object to display "current page" or whatever. Hope that helps. David Navas navas@cory.berkeley.edu "The crudest form of a working program is a program that doesn't work." -me [Senior EECS major. Also try c186br@holden, c260-ay@ara and c184-ap@torus]
peter@sugar.hackercorp.com (Peter da Silva) (02/01/91)
In article <1991Jan31.011702.12095@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: > Well this will probably cause some flames, but this is an example of > where the Mac is MORE customizable than the Amiga... i.e. where the > user can make things work the way he wants, not the way the OS wants. The Amiga lets any system function be redefined, but currently doesn't allow redefinition of gdgets. That will change when 2.0 becomes widely available, thanks to gadtools. In the meantime the library calls can be modified to get a similar effec6t but it's not encouraged. I assumed you were talking about something a well-behaved application might want to do. You can, of course, modify anything in an optional utility that isn't going to break your ability to use the application if things change in a new release of the O/S. One of the things *I* like about the Amiga is that Commodore has never been shy of breaking badly behaved apps when a new release came out so we're not *so* badly held back by the installed base... > Can you have callback functions.. i.e. get Intuition to call your > function while it's moving the knob? Not under 1.3, but you can under 2.0. On the other hand your program receives continuous messages while the knob is moving: the Amiga does things that the Mac does with callbacks by means of passing messages between separate tasks. Remember, intuition has a different task context, so a callback has to be particularly careful. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
torrie@cs.stanford.edu (Evan J Torrie) (02/01/91)
rjc@geech.ai.mit.edu (Ray Cromwell) writes: >In article <1991Jan31.011702.12095@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: > Well the Amiga can do this too, but its not officially supported. >Programs can use input handlers to get mouse/key events before >intuition gets them, programs can SetFunction() OpenWindow, programs >can open their own screen and uses layer's to implement their own >windowing system. This sounds like more of a hacky solution that the Apple method of having a window definition function. Each definition function must accept and reply to a set of messages which the OS can send it (e.g. DrawFrame, CalcRgns etc.) This function is compiled as a code segment into a WDEF resource. Each WDEF resource can have its own ID. Normally programs just use the default ID (=0), which corresponds to the standard Mac window you see on every Mac desktop. Since this is stored in ROM, and resource which are in open files can override ROM resources, you can put your own WDEF ID=0 resource in the System file (which is kept open), and every application automagically calls your WDEF code (and hence generates whatever kind of window shape/shade you want). >> Can you have callback functions.. i.e. get Intuition to call your >>function while it's moving the knob? > Not that I know of. I wouldn't want it. The places where it is used on the Mac, is in programs which want to do dynamic updating of displays such as the page number in MacWrite/line number in Excel (i.e. as the scroll box is dragged, a number in the status bar is updated to reflect which line you will end up on if you let go of the mouse button now). How would you do a similar thing on the Amiga? If you put code in the input handler to do this, then it once again means your input handler needs to know about the internal data structures of your application. >Since when does the Mac have a NeXT/Motif look? If so, is it a PD hack >and where can I get it? I want to try it on my friends Amax. I think >plain old finder looks horrible, and so do many of the Mac requestors. >AmigaDOS 2.0 makes the Mac look like C64 GEOS. There are plenty of Mac PD window-changers, control-changers... Things like AltWDEF, AltCDEF and a host of others. One of the archive sites will probably have them (e.g. sumex-aim.stanford.edu). There are also two commercial programs which do similar things (ClickChange and Personality). Also interesting is that the firm doing a MacClone (NuTek?) has a Motif style interface to avoid lawsuits. From the screenshot I saw, they even had nice things like the menu-bar inside the window of the running application! -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "She's got a tongue like an electric eel, and she likes the taste of a man's tonsils!" - Rik Flashheart
bartonr@eecs.cs.pdx.edu (bartonr) (02/02/91)
From: rjc@geech.ai.mit.edu (Ray Cromwell)
> Every Amiga window contains a Border structure.
No it doesn't, at least not as of version 34.3 of Intuition. A Gadget
structure may contain a pointer to a Border structure, however.
================================================================================rjc@geech.ai.mit.edu (Ray Cromwell) (02/03/91)
In article <1410@pdxgate.UUCP> bartonr@eecs.cs.pdx.edu (bartonr) writes: >From: rjc@geech.ai.mit.edu (Ray Cromwell) >> Every Amiga window contains a Border structure. > > No it doesn't, at least not as of version 34.3 of Intuition. A Gadget >structure may contain a pointer to a Border structure, however. > >================================================================================ Opps! Freudian Slip.. I got it mixed up with the requester structure. You can still change the look of windows with DrawBorder(). Check out Software Distillery's HackLite. They used Borders to make windows look like scrolls I believe. And if you really want fancy windows there's struct Image/DrawImage() or BltBitMapRastPort().
easu052@orion.oac.uci.edu (Thu Ra Tin) (02/03/91)
In article <1991Feb1.153430.7254@mintaka.lcs.mit.edu> rjc@geech.ai.mit.edu (Ray Cromwell) writes: >In article <1991Feb1.032445.15245@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: >>rjc@geech.ai.mit.edu (Ray Cromwell) writes: >> >>>In article <1991Jan31.011702.12095@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: >>> Well the Amiga can do this too, but its not officially supported. >>>Programs can use input handlers to get mouse/key events before >>>intuition gets them, programs can SetFunction() OpenWindow, programs >>>can open their own screen and uses layer's to implement their own >>>windowing system. >> >> This sounds like more of a hacky solution that the Apple method of >>having a window definition function. Each definition function must >>accept and reply to a set of messages which the OS can send it (e.g. >>DrawFrame, CalcRgns etc.) This function is compiled as a code segment >>into a WDEF resource. > > Input handler's are not hacks, and neither are changing the interface >via layer's library. Evidently, you don't much about the Amiga or >its interface. Its possible to totally change a window's look without >much work. Every Amiga window contains a Border structure. A border >structure consists of a set of points and colors to render for the border >of the Window. (Border structures are general purpose, they can be used >with anything as there is a DrawBorder() function.) It's also possible to >change the gadget imagery on the Amiga quite easily, and there are a number >of programs like ReplaceGadgets, Newlook,etc that do this. > >>-- >>------------------------------------------------------------------------------ >>Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu >>"She's got a tongue like an electric eel, and she likes the taste of a >> man's tonsils!" - Rik Flashheart If you guys want to see a comparison of system calls on the Mac and Amiga there is a really good article in September 1986 issue of BYTE written by the programmer who wrote TRUE basic for both computers. It's on page 250.
peter@sugar.hackercorp.com (Peter da Silva) (02/03/91)
In article <1991Feb1.032445.15245@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: > This sounds like more of a hacky solution that the Apple method of > having a window definition function. It is. Each system has their own strengths. The Amiga's is the basic system software: it's by far the best commercial system shipped with any PC for any price. Apple's Multitasking Charade using the DAs hooks is a kludge by comparison. And the Amiga's method of changing global window behavior at the lowest level is a kludge compared to what the Mac does. A saving grace to the Amiga's method is that it can be done efficiently without making normal applications unnecessarily chummy with the window system internals. And the Amiga's method of handling higher level events through messages is *much* cleaner. Message passing is about the easiest way to synchronise concurrent processes and pass information betwen them. > The places where it is used on the Mac, is in programs which want to > do dynamic updating of displays... > How would you do a similar thing on the Amiga? You set the gadget to send MOUSEMOVE messages and update the number in the display as you get MOUSEMOVE messages from that gadget. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (02/03/91)
In article <1991Jan31.061011.28172@cunixf.cc.columbia.edu> es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: > SIZEVERIFY > "You set this flag if your program is drawing to the > window in such a way that the drawing must be finished before the > user sizes the window. If the user tries to size the window, a > message is sent to the application and Intuition will Wait() > until the program replies. ..." I don't think that's what Evan was thinking of. He was more talking about getting a request to handle window sizing from the O/S (through a callback) and managing the whole action itself. This is more along the lines of giving the program fair notice before resizing so it can clean up anything it might be doing. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
davewt@NCoast.ORG (David Wright) (02/04/91)
In article <1991Jan31.011702.12095@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: >peter@sugar.hackercorp.com (Peter da Silva) writes: > >>> Can your program get its hooks into this event BEFORE the OS gets >>> hold of it and "do its own thing"? > >>Nope. You can tell Intuition the bounds you're willing to let the user manage >>the window within, but that's it. He was wrong. > > For example, all the hooks into window definition functions, menu >definition functions, etc... where you can roll your own code, and >make your own windows/menus etc... this is how the Mac gets all those >nice NeXT/Motif type windows without having to rewrite existing >program code. For an example of this on the Amiga, pick up any number of PD programs that will let you change the appearance of the gadgets without changing any program. And on the Amiga anyone is free to write a new library that does whatever type of window trickery they wish, but most people probobly won't like it. > Can you have callback functions.. i.e. get Intuition to call your >function while it's moving the knob? I'm not sure, but I am almost certain from looking in the manual that your program can receive "gadget moved" messages everytime the gadget moves one notch, which would work functionally the same as a callback. The reason you probobly need these on the Mac is that the Mac tends to treat gadgets as a private thing, which return a certain value to the caller, and without a call back function, you would not be able to do (extra) things while the gadget was selected and being moved (in the special case of the scroll bar, since most other gadgets on both systems return only the selected/ unselected type messages). The file requester provides a way to supply call back functions, if you need to add more gadgets to the requestor for special purposes, or you want to do things while the requester is pulling up a list of files, for example, so I would assume that such a feature is provided elsewhere, if needed. Dave