🚀 go-pugleaf

Yeah, its really too bad that Object Model support got lost in the rush to
Bedrock. However it's really not that hard to do yourself, but it does require
modifying MacApp a good bit. But, I tell myself, since we'll never see a new
version of MacApp, I might as well go to town on its source code.
 
Eric's article is a great example, but as you noted doesn't mention MacApp.
This is not an accident, as I discovered when I linked him looking for advice
on how to apply the same example to MacApp. He replied that a MacApp example
"involves too much pain and anguish to deal with in a single
article." After working on this a bit, I have to agree with him.
 
His advice for using the example in his artice with MacApp went like this:"
 
1) Put all the MAppleObject behavior into TObject. For the pure virtual
functions, write TObject implementations that call SubclassResponsibility.
This will cause a runtime break, thus implementing the "pure virtualness" of
the object.
 
2) Change TApplication's handling of AppleEvents to check the direct object
just as my C++ dispatcher object does. Dispatch to the appropriate object if
it is an object model event, and to gApplication if not (ie: gApplication will
always be the "default handler")."
 
This puts the basic structure in place for handling the Object Model, but
doesn't implement default functionality for TWindow, TView,
TEventHandler, TApplication, etc. Eric noted that this requires most of the
work. It does, but is mostly tedious, not technically difficult.
 
Of course this does not address making the application recordable in addition
to being scriptable. This will require some modifications to the TCommand
system I'm sure, but I think I'll drive off that bridge when I come to it.
 
Ken Ryall