uucibg@swbatl.UUCP (3929) (09/26/89)
Please forgive if this has been talked to death previously (in which case
I'd appreciate it if someone could fill me in on the results)...
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
... ... ... ...
But now what beast does one's program get one of these from? Does one create
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?
How does MacApp handle this? What other approaches are there?
Thanks much,
--------------------------------------------------------------------------------
Brian R. Gilstrap ...!{ {killer,bellcore}!texbell, uunet }!swbatl!uucibg
One Bell Center +----------------------------------------------------------
Rm 17-G-4 | "Winnie-the-Pooh read the two notices very carefully,
St. Louis, MO 63101 | first from left to right, and afterwards, in case he had
(314) 235-3929 | missed some of it, from right to left." -- A. A. Milne
--------------------------------------------------------------------------------
Disclaimer:
Me, speak for my company? You must be joking. I'm just speaking my mind.awd@dbase.UUCP (Alastair Dallas) (09/27/89)
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/
lsr@Apple.COM (Larry Rosenstein) (09/27/89)
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