CompuServe Thread

Quicksand, so far, is capable of instantiating low-level Operating System events. By tomorrow, it should be able to parse them to see whether they are mouseDown, mouseUp, etc. From there, I should have a working menu bar with menus and items by the middle of next week. That will enable me to choose "Quit" from the File menu, so that I can run it outside the Symantec Project Manager. From there, everything else should be easy…. I quess you might say I'm in up to the tip of my big toenail. But I'm having fun. The point of all this is to see how far I can go breaking the most basic Macintosh application functionality out into separate C++ classes. I have the impression the Bedrock project is pursuing this direction, too. For example, my CApplication class does not contain an event loop. Instead, the event loop is in a separate class, somewhat like Symantec's Think Class Library does it with the "Switchboard". But in Quicksand, the individual events are not coded procedurally, as in TCL. Instead, each event record pulled in with WaitNextEvent is shoved into a new instance of an event class. The CEvent abstract class is overridden for low-level event objects, Apple event objects, etc., and each of the overridden event classes does the dispatching of the event to appropriate places (like a DoMouseDownHandler, etc.). Does this make sense? I find so far that it is quite useful to encapsulate events at such a low level, and I am hopeful that there won't be much of a performance hit. I'll be following the same philosophy all the way up the line (e.g., a separate class for menu items?).