Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!gem.mps.ohio-state.edu!ginosko!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.lang.c++ Subject: Re: Combining event driven and object orient programming Message-ID: Date: 9 Oct 89 19:03:29 GMT References: <13928@well.UUCP> <13929@well.UUCP> <14004@well.UUCP> Sender: davidm@cimshop.UUCP Distribution: all Organization: Consilium Inc., Mountain View, California. Lines: 28 In-reply-to: nagle@well.UUCP's message of 8 Oct 89 19:07:57 GMT In article <14004@well.UUCP> nagle@well.UUCP (John Nagle) writes: That approach results in a mode. If you want a modeless event processing model, as the Apple Human Interface Guidelines suggest, such an approach is inappropriate. You should be able to do anything at any time unless there is some pressing reason to prohibit inherently incompatible actions. How can I get hold of the Apple Human Interface Guidelines? Does it make sense in an object-oriented world (particularly C++)? How much analysis of the proposed application is required for this model (it doesn't sound like much, just a particular mindset that I haven't assimilated yet with C++ in mind). It seems to me that having a "pressing reason" would be more the norm in most situations (again, probably a mindset problem). You fork off a task when there's no need to wait for the result. Suppose the application can open various kinds of documents, but opening may be time-consuming. Having initiated opening of a document, the user should be free to make further selections and open more documents while the first document opens. Would not these subtasks also have event loops of their own? There's something recursive in this definition that I'm having trouble following. In the C++ paradigm, would opening a document be considered constructing an object or more of a message to an object that was already constructed (the document opener task)? David Masterson uunet!cimshop!davidm