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/