[Openmcl-devel] One last (I hope) Cocoa question

[Paul Krueger]

I'm not sure if this will work for you, but you can also override  
validateMenuItem: for your documents and let it decide whether or not  
the save menuitem is enabled. I did that in one of my interface  
examples for my own documents:

(objc:defmethod (#/validateMenuItem: #>BOOL)
                 ((self loan-doc) (item :id))
   (let* ((action (#/action item)))
     (cond ((eql action (ccl::@selector #/saveDocument:))
            (#/isDocumentEdited self))
           (t (call-next-method item)))))

I found that the normal save functionality then worked just fine for  
my documents. You might want a different test to determine whether to  
enable it in your case. Of course if the save functionality itself  
fails in your example for some reason that's a different story.

Paul

On Jan 25, 2010, at 12:52 PM, Ron Garret wrote:

> I think I have all the pieces working that I need to integrate a  
> revision control system into Hemlock.  I can grab snapshots on every  
> save by intercepting GUI::WRITE-HEMLOCK-BACKUP-FILE, and I can  
> rollback by using the underlying RCS to rollback the file and then  
> invoking hemlock-ext:revert-hemlock-buffer.  All that works, but  
> there is a hitch: once the RCS has swapped out the underlying file  
> (so that it now has a different inode), Cocoa won't let you save it  
> any more, except by doing a SAVE-AS, which is annoying.  I can work  
> around this by closing the editor window and then re-opening a fresh  
> one on the (now new) file, but that seems like a Horrible Hack.   
> Does anyone know of a way to convince an NSDocument to reconnect  
> itself to a file with the same name but a different inode?
>
> Thanks,
> rg
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel