Donald McElheny wrote: > Why does CS use the OSXDelegate2D class as an alternative to NSResponder > for mac os x clients (as opposed to having OSXDelegate2D inherit from > NSResponder and overriding methods whose functionality it wishes to > change)?
I am not certain that I fully understand your question. Generally speaking, in the AppKit, delegates are objects which provide some functionality to extend or augment behavior of some other object without having to be derived from any specific class. If you come from a Java or C# background, you can think of a delegate loosely as an object implementing an "informal" interface. The delegate architecture allows the same implementation to be employed in a wider range of situations. For instance, consider two different external projects with their own NSView or NSWindow subclasses. The one delegate implementation from CS may be able to work cleanly with those custom subclasses. The delegate architecture also allows the same object to augment behavior of more than one client. For instance, OSXDelegate2D is the delegate for both the NSWindow and the NSView. (That is not to say that this is a necessarily good architectural choice, but it is an example where the arrangement probably simplified implementation.) A similar argument applies to OSXDelegate as a stand-alone delegate rather than an NSResponder subclass. All of the responder-like methods which you see in the interface are merely convenience methods for converting AppKit events to CS events and enqueuing them. These are worker functions invoked by objects which actually are NSResponder subclasses, such as OSXView and perhaps OSXWindow. It was natural to use responder-like names for these utility methods in OSXDelegate2D, but it would be misleading for OSXDelegate itself to be derived from NSResponder. That said, OSXDelegate nevertheless is a bit of a wart in that it has to be the NSApplication delegate. This is necessary since there are certain delegate methods from the application, such as -applicationDefined:, -togglePaused:, -applicationDidBecomeActive:, -applicationDidHide:, etc. , which it implements in order to drive the CS run-loop. The problem with this approach is that it makes it difficult for a CS-based project to provide its own NSApplication delegate, a common requirement. -- ES ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Crystal-main mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/crystal-main Unsubscribe: mailto:[email protected]?subject=unsubscribe
