[Openmcl-devel] What goes on under the hood during revert

[Ron Garret]

Great pointers.  Thanks!

rg

On Jan 24, 2010, at 10:44 PM, mikel evins wrote:

> 
> On Jan 24, 2010, at 1:59 PM, Ron Garret wrote:
> 
>> Trying to trace through the process of what happens when you revert a document...
>> 
>> The REVERT menu item invokes revertDocumentToSaved: (as can be determined with this handy-dandy little snippet):
>> 
>> ? (%get-cstring (#_sel_getName (menu-item-action-selector "File" "Revert")))
>> "revertDocumentToSaved:"
>> 
>> As far as I can tell, this method is not overridden anywhere in the GUI sources, so this just does the standard Cocoa thing, namely, displays the "Are you sure?" dialog, and then invokes....
>> 
>> ... and that's where I get very puzzled, because the latest docs say it invokes revertToContentsOfURL:ofType:error:, which is also, as far as I can tell, not overridden anywhere.  What *is* overridden is revertToSavedFromFile:ofType: but that method is deprecated in Leopard, and as far as I can tell (by adding a print statement) this method is in fact not invoked when a file is reverted.
>> 
>> OK, so maybe the code overriding revertToSavedFromFile:ofType: is just dead code in Leopard, but it sure seems to do an awful lot of work.  It seems improbable to me that all that code just fall on the floor without causing some negative repercussions.  But what do I know?
>> 
>> Any light that anyone can shed on this would be much appreciated.  I'm as much interested in learning how I should be approaching a situation like this in general as I am about getting the specific answer in this case -- teach a man to fish and all that.
> 
> Cocoa consists of a lot of standard classes and messages that get called when events are signaled. Some of them do actually useful things (which is why you can build a functional text editor is no few lines of code). A lot of them don't actually do anything useful, except insofar as providing a place to hang code is useful.
> 
> The general idea is that a lot of the messages provide scaffolding on which you can hang code that does stuff, and that you can rely on to be called when events are signaled. There is some cognitive overhead in learning your way around the maze of standard events and messages, but after you've been doing it for a little while, it starts to get pretty easy to guess where to look to find the hook you need to hang your code on.
> 
> So you are probably not wrong that the code you were looking at doesn't really do anything--or rather, that it doesn't do anything other than provide a convenient place to hang your code, and make your code especially small and to the point.
> 
> Once you get accustomed to the way Cocoa is organized, it really is pretty easy to build apps by hanging a few strategicall-placed Lisp functions off a few pieceos of the framework (thanks to CCL's great bridge).
> 
> Generally, in the learning stage you're talking about, the best approach is going to be to read documents like this one:
> 
> http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/Documents/Documents.html
> 
> ...which will help you begin to figure out what the parts are and how they fit together. There are vast piles of that stuff, and it's really daunting at first, but after some threshold that doesn't seem to take too long, you start to develop and intuition about where to look for stuff. Once you have that, then this app will be a big help:
> 
> http://homepage.mac.com/aglee/downloads/appkido.html
> 
> You might also want to grab this book:
> 
> http://www.amazon.com/exec/obidos/ASIN/0321503619/bignerdranch-20
> 
> It's pretty much a start-to-finish how-to about building a Cocoa app. Just skimming through it once really quickly will probably help enormously in figuring out where to look for stuff.
> 
> --me
> 
>