Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!apple!Apple.COM!lsr From: lsr@Apple.COM (Larry Rosenstein) Newsgroups: comp.sys.mac.programmer Subject: Re: Events and classes (OO-stuff) Message-ID: <4381@internal.Apple.COM> Date: 26 Sep 89 22:01:22 GMT References: <817@swbatl.UUCP> Sender: usenet@Apple.COM Organization: Objects-R-Us, Apple Computer, Inc. Lines: 77 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". [class hierarchy omitted] > But now what beast does one's program get one of these from? Does one This is a good question. In the case of Macintosh events, there is a mismatch. Events are put into the event queue as structures, not objects. So as you recognized, there has to be some code to create objects out of the data. I think there is no way to avoid a CASE statement somewhere in the program, whose job it is to do this. If PostEvent accepted an object and the event queue held objects then this wouldn't be necessary. So given that you write a CASE statement to convert each event to an object, the class hierarchy you suggested would be workable. The generic Event class would contain things such as the event timestamp, modifyer key state, etc. One method that could be defined there is Distribute, which would send the even to the appropriate object for processing. > an "EventQueue" class or some such thing whose "new" method/member function > returns instance of different classes (some sub-class of Event) or some > such thing? An EventQueue class could have a Pop method that gets the next event (by calling GetNextEvent), does a CASE statement on the event type, creates the appropriate Event object and returns the object. (It could also do this for all the events in the queue and keep then in an internal queue.) > How does MacApp handle this? What other approaches are there? In MacApp we have method in the TApplication object that take the raw events from the event queue and categorize the events (key down, mouse down in content, mouse down in close box, etc.). The code to do this is the same as you would write in a regular program. There is a separate method for each kind of event, which gets called when that event is seen. MacApp doesn't create (or define) and event objects. It didn't seem worthwhile to create an event object, just to have an object. There are only a small number of different kinds of events and the events have a short lifetime. Also, the code to categorize the events is pretty standard, and is not something that applications need to change. (You don't normally want clicking in the close box to do soemthing other than close the window.) One could ask the same question about menu commands. I think the answer would be similar. Again, the Toolbox deals with menu commands in terms of menu/item numbers. You could define MenuItem objects, but you would still need to use a CASE statement to convert the menu/item numbers to an object. MacApp does this in a general sense. We convert the menu/item numbers to a single command number (which allows yo to rearrange the menu items without recompiling), and the programmer writes a CASE statement based on the command number. Most commands are handled by creating a command object and returning it to MacApp. One could imagine ways to do this that wouldn't require a CASE statement (have a hash table mapping a command number to a command object), but the CASE statement is more flexible (you can do an arbitrary test to decide what command object to return). Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1