[Openmcl-devel] One last (I hope) Cocoa question
ron at flownet.com
Mon Jan 25 23:26:38 UTC 2010
Thanks! I'll try that and Gary's idea (but I seem to be catching the flu so it might be a couple of days before I get to it).
On Jan 25, 2010, at 12:41 PM, Paul Krueger wrote:
> 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.
> 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?
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
More information about the Openmcl-devel