Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!ginosko!usc!hacgate!ashtate!dbase!awd
From: awd@dbase.UUCP (Alastair Dallas)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Events and classes (OO-stuff)
Summary: Novice answer
Keywords: events, sub-classing, things popping out of nowhere
Message-ID: <257@dbase.UUCP>
Date: 26 Sep 89 18:53:41 GMT
References: <817@swbatl.UUCP>
Organization: Ashton Tate Devlopment Center Glendale, Calif.
Lines: 30

In article <817@swbatl.UUCP>, uucibg@swbatl.UUCP (3929) writes:
> How does one go about handling things like events object-orientedly?  It
> is kind of a problem in the sense that you've got these different kinds of
> events popping out of "nowhere" (from the OS event queue).  I've used the
> rule of thumb "if you consider using a case statement, then it ought to be
> a method/member function in a bunch of classes".  This would seem to argue
> something like:
> 
> 
>                              Event
>                                |
>     +-----------------+--------+------------+-------------+
>     |                 |                     |             |
> KeyEvent          WindowEvent           MouseEvent     DiskEvent
>   ...                 ...                  ...            ...

There are some real experts on this newsgroup--me, I'm a novice.  But I am
familiar with the fact that THINK C 4.0 and MacApp define a general class of
objects which are capable of handling events (CBureaucrat in TC4 and 
TEvtHandler in MacApp).  The nature of things like mouseDown events is
that you need a switch to find who wants to handle the event: menu bar,
system window, document, tool pallette, etc.  The way TC4 handles this
is that windows and pallettes and things are a "bureaucrats," in that 
if they can't respond to an event, they pass it along to their supervisor.
So you're structure ends up with a chain of command, passing events from
one specialized bureaucrat to another until one of them handles it.

Hopes it helps.

/alastair/