Re: Where and how do I know a save completed successfully?

[Quincey Morris]

On May 8, 2015, at 17:50 , Charles Jenkins  wrote:
> 
> I tell the text view its delegate is my Document instance as soon as possible 
> in windowControllerDidLoadNib: 

I don’t know the timing offhand, but it’s possible that the text view looks for 
its undo manager earlier. I’d suggest you hook up its delegate outlet in IB, 
which means you’ll need to make the window controller its delegate, not the 
document (unless, that is, you’re using the document subclass as File’s Owner 
for the document window NIB). The window controller should already have its 
“document” property set, but you should verify this and if necessary get hold 
of the document some other way.

The details would be different if you’re using a storyboard, but the window 
controller is still there to be connected as delegate.

If this continues to be problematic, you might want to examine the source code 
for TextEdit, which presumably addresses the undo controller issue in much the 
same way that you want.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Where and how do I know a save completed successfully?

[Charles Jenkins]

On May 8, 2015 at 1:09:01 PM, Quincey Morris 
(quinceymor...@rivergatesoftware.com) wrote:
In this case, the text view should probably use the document undo manager, 
though you may have to do extra work to coordinate its use with your document’s 
needs. To configure it, you should tell the text view what its undo manager is, 
via its ‘undoManagerForTextView:’ delegate method.


My NSTextViewDelegate section begins like this:

extension Document : NSTextViewDelegate {  /// Plug document undo manager into 
the text v

  func undoManagerForTextView( view:NSTextView )
    -> NSUndoManager?
  {
    var um = self.undoManager
    describeUndoManager( um, 
source:"NSTextViewDelegate.undoManagerForTextView:" )
    return self.undoManager
  }

I think the delegate is good, because its other methods get called. But this 
one doesn’t. I tell the text view its delegate is my Document instance as soon 
as possible in windowControllerDidLoadNib: — right after I test and find that 
my Document’s undoManager is NOT nil. So the situation remains that the 
Document has an undoManager, but the text view’s undoManager variable remains 
nil throughout execution. Is there still a step I’m missing?
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Where and how do I know a save completed successfully?

[Quincey Morris]

On May 8, 2015, at 02:46 , Charles Jenkins  wrote:
> 
> I may have a fundamental misunderstanding of how a document class, a text 
> view, and an undo manager work together.

It depends a bit on what kind of editing your document can have done to it.

> I already tried plugging the document’s undoManager into the text view after 
> the NIB loads, but the text view’s undoManager property isn’t directly 
> settable.

If you wanted a text view to use the document’s undo manager, you *could* 
implement the ‘windowWillReturnUndoManager:’ NSWindowDelegate method to return 
it. That is, you would do this in your window controller, or in your NSDocument 
subclass if you aren’t using a window controller, whichever is hooked up as the 
window delegate.

I’m not sure, though, that this is what’s generally wanted. If you do so, then 
the keystroke undo for every text view and text field will live in your 
document’s undo chain, and that almost certainly isn’t what you want.

Undo for text fields (and text views when the content isn’t directly your 
document content) is usually handled by the window-provided freestanding undo 
manager. In document-based apps, changes to the model are generally handled by 
end-editing notifications, delegate methods or bindings, and uncommitted text 
changes are dealt with via the “informal” NSEditor and NSEditorRegistration 
protocols. (Note that NSViewController and NSDocument implement support for 
these, but NSWindowController doesn’t, which is a big PITA.) In these 
scenarios, a separate window-specific undo manager is all you need.

> As a text editor, shouldn’t my app have just one undo manager for each 
> Document, one that works for the document window and the text view contained 
> within it? If so, how do I configure that?

In this case, the text view should probably use the document undo manager, 
though you may have to do extra work to coordinate its use with your document’s 
needs. To configure it, you should tell the text view what its undo manager is, 
via its ‘undoManagerForTextView:’ delegate method.

I think that if you supply an undo manager this way, the text view won’t ask 
the window for its undo manager, so you avoid the 
‘windowWillReturnUndoManager:’ process and the danger of getting tangled up 
with undo actions for other editing controls in the same window.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Where and how do I know a save completed successfully?

[Charles Jenkins]

I may have a fundamental misunderstanding of how a document class, a text view, 
and an undo manager work together.

I made these override functions in my Document class:

  override func updateChangeCount( change:NSDocumentChangeType ) {
    println( "updateChangeCount:" )
    super.updateChangeCount( change )
    if change == .ChangeCleared {
      println( "Change count cleared. Now clearing modification flags" )
      project.resetModificationFlags()
    }
  }

  override func updateChangeCountWithToken(
    changeCountToken:AnyObject,
    forSaveOperation saveOperation:NSSaveOperationType
  ) {
    println( "updateChangeCountWithToken:forSaveOperation:" )
    let before = documentEdited
    super.updateChangeCountWithToken( changeCountToken, 
forSaveOperation:saveOperation )
    let after = documentEdited
    println( "Before=\(before); after=\(after)" )
    project.resetModificationFlags()
  }

I start my app and type some junk in the main window’s text view, where Undo 
works, then save.

updateChangeCount: is never called, ever. I expected it to be called upon 
changing text in the text view and again upon saving.

updateChangeCountWithToken:forSaveOperation: is called after saving, but the 
“before" and “after" flags are both FALSE, meaning that my typing in the text 
view didn’t cause the document to be marked as edited. 

Here’s the way I thought things worked: the first time you type into a text 
view, it needs to get an undo manager in order to put the change on its undo 
stack. Unless you do something special, it will get the window’s undo manager, 
which will also (for a document window) be the document’s undo manager. So I 
thought I’d be dealing with exactly one undo manager. When the undo stack 
contains operations, the change count is non-zero, and the document knows it 
has been edited.

Somehow, that’s not all true for me. At the time 
updateChangeCount:forSaveToken: is called, the document’s undoManager property 
returns a value: an undoManager with zero levelsOfUndo, which may mean it’s 
going unused. The text view’s undoManager property returns nil.

I already tried plugging the document’s undoManager into the text view after 
the NIB loads, but the text view’s undoManager property isn’t directly settable.

As a text editor, shouldn’t my app have just one undo manager for each 
Document, one that works for the document window and the text view contained 
within it? If so, how do I configure that?

— 

Charles

On April 29, 2015 at 10:19:22 AM, Uli Kusterer (witness.of.teacht...@gmx.net) 
wrote:

On ٢٩‏/٠٤‏/٢٠١٥, at ١١:٠٨, Charles Jenkins  wrote:
I think it most likely I’m doing this in the wrong place. But what’s the right 
place? Overriding NSDocument’s setFileModificationDate() would seem like the 
best way, but the NSDocument Programming guide says messages are sent to 
setFileURL:, setFileType: and setFileModificationDate: “if appropriate,” so I’m 
not sure I can count on getting that message.

 I don't think that's a good spot, as it isn't explicitly connected to file 
saving. I'd try updateChangeCount: instead, and check for NSChangeCleared.

 Also, keep in mind that "Save to..." and the likes also may get used on your 
document, saving to a different file but (IIRC) leaving the original document 
dirty. Maybe I'm misremembering what they do, but all those definitely need 
testing.

-- Uli
http://stacksmith.org
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Where and how do I know a save completed successfully?

[Charles Jenkins]

Thank you, Uli and everyone. I’ll check out updateChangeCount:

I did file a bug report about the compiler crash caused by my syntax.

— 

Charles

On April 29, 2015 at 10:19:22 AM, Uli Kusterer (witness.of.teacht...@gmx.net) 
wrote:

On ٢٩‏/٠٤‏/٢٠١٥, at ١١:٠٨, Charles Jenkins  wrote:
I think it most likely I’m doing this in the wrong place. But what’s the right 
place? Overriding NSDocument’s setFileModificationDate() would seem like the 
best way, but the NSDocument Programming guide says messages are sent to 
setFileURL:, setFileType: and setFileModificationDate: “if appropriate,” so I’m 
not sure I can count on getting that message.

 I don't think that's a good spot, as it isn't explicitly connected to file 
saving. I'd try updateChangeCount: instead, and check for NSChangeCleared.

 Also, keep in mind that "Save to..." and the likes also may get used on your 
document, saving to a different file but (IIRC) leaving the original document 
dirty. Maybe I'm misremembering what they do, but all those definitely need 
testing.

-- Uli
http://stacksmith.org
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Where and how do I know a save completed successfully?

[Michael Crawford]

> 1. The compiler crash should never happen, obviously, so that's a bug report.

To be more clear - it doesn't matter how screwed up your source could
possibly be, the compiler must never crash.  If it does, then it's a
bug in the compiler.

It's quite likely that a slightly more subtle problem in your source
would result in incorrect machine code generation.  I've actually seen
that happen.  In my case I knew I was getting bad machine code;
increasing the number of characters in certain symbol names lead to
the MPW C compiler setting my Mac up the bomb.
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/

   Available for Software Development in the Portland, Oregon Metropolitan
Area.


On Wed, Apr 29, 2015 at 10:22 AM, Quincey Morris
 wrote:
> On Apr 29, 2015, at 02:08 , Charles Jenkins  wrote:
>>
>> override func saveToURL(
>> url:NSURL,
>> ofType typeName:String,
>> forSaveOperation saveOperation:
>> NSSaveOperationType,
>> completionHandler:(NSError!) -> Void
>>   ) {
>> //  Here I prepare my data structures for saving
>>
>> //super.saveToURL( url, ofType:typeName, forSaveOperation:saveOperation, 
>> completionHandler:completionHandler )
>>
>> super.saveToURL(
>>   url,
>>   ofType:typeName,
>>   forSaveOperation:saveOperation,
>>   completionHandler:{
>> ( error:NSError! ) -> Void in {
>>   completionHandler( error )
>>   // TODO: If no error, mark data structures as "clean"
>> }
>>   }
>> )
>>   }
>
> 1. The compiler crash should never happen, obviously, so that's a bug report.
>
> 2. The bridged protocol method is apparently wrong. Since the error parameter 
> is explicitly documented as being nil on success, it should be NSError?. 
> (Note that it's possible at runtime for an implicitly unwrapped optional (!) 
> to be nil, and you can test for it being nil, but we saw in your previous 
> adventure that an app will crash if the Swift runtime tries to enter a Swift 
> method with a nil value for an implicitly unwrapped optional, at least when 
> coming from the Obj-C runtime).
>
> 3. The bridged method signature isn't syntactically correct, though it isn't 
> exactly wrong either. There's no need for parentheses in '(NSError!)'. A 
> 1-tuple is by definition the same thing as the element in the tuple, but I 
> wouldn't be surprised if the compiler doesn't handle this in all cases.
>
> 4. Similarly, the parentheses in your super invocation aren't necessary, nor 
> is the default return type (... '( error:NSError! ) -> Void in' ...).
>
> 5. It's not necessary to open an new brace after 'in', though this shouldn't 
> be wrong either.
>
> So, that's a lot of slightly unusual stuff, and the crash could be caused by 
> any one of them. In Xcode 6.3.1, the following compiles for me without 
> errors, warnings or a compiler crash:
>
> override func saveToURL(url: NSURL, ofType typeName: String, 
> forSaveOperation saveOperation: NSSaveOperationType, completionHandler: 
> NSError? -> Void) {
> super.saveToURL(url, ofType: typeName, forSaveOperation: 
> saveOperation) {error in /*...*/ return}
> }
>
> See if that works for you. (But don't forget your bug report!)
>
>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/mdcrawford%40gmail.com
>
> This email sent to mdcrawf...@gmail.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Where and how do I know a save completed successfully?

[Quincey Morris]

On Apr 29, 2015, at 02:08 , Charles Jenkins  wrote:
> 
> override func saveToURL(
> url:NSURL,
> ofType typeName:String,
> forSaveOperation saveOperation:
> NSSaveOperationType,
> completionHandler:(NSError!) -> Void
>   ) {
> //  Here I prepare my data structures for saving
> 
> //super.saveToURL( url, ofType:typeName, forSaveOperation:saveOperation, 
> completionHandler:completionHandler )
> 
> super.saveToURL(
>   url,
>   ofType:typeName,
>   forSaveOperation:saveOperation,
>   completionHandler:{
> ( error:NSError! ) -> Void in {
>   completionHandler( error )
>   // TODO: If no error, mark data structures as "clean"
> }
>   }
> )
>   }

1. The compiler crash should never happen, obviously, so that’s a bug report.

2. The bridged protocol method is apparently wrong. Since the error parameter 
is explicitly documented as being nil on success, it should be NSError?. (Note 
that it’s possible at runtime for an implicitly unwrapped optional (!) to be 
nil, and you can test for it being nil, but we saw in your previous adventure 
that an app will crash if the Swift runtime tries to enter a Swift method with 
a nil value for an implicitly unwrapped optional, at least when coming from the 
Obj-C runtime).

3. The bridged method signature isn’t syntactically correct, though it isn’t 
exactly wrong either. There’s no need for parentheses in ‘(NSError!)’. A 
1-tuple is by definition the same thing as the element in the tuple, but I 
wouldn’t be surprised if the compiler doesn’t handle this in all cases.

4. Similarly, the parentheses in your super invocation aren’t necessary, nor is 
the default return type (… '( error:NSError! ) -> Void in’ …).

5. It’s not necessary to open an new brace after ‘in’, though this shouldn’t be 
wrong either.

So, that’s a lot of slightly unusual stuff, and the crash could be caused by 
any one of them. In Xcode 6.3.1, the following compiles for me without errors, 
warnings or a compiler crash:

override func saveToURL(url: NSURL, ofType typeName: String, 
forSaveOperation saveOperation: NSSaveOperationType, completionHandler: 
NSError? -> Void) {
super.saveToURL(url, ofType: typeName, forSaveOperation: 
saveOperation) {error in /*…*/ return}
}

See if that works for you. (But don’t forget your bug report!)



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Where and how do I know a save completed successfully?

[Uli Kusterer]

On ٢٩‏/٠٤‏/٢٠١٥, at ١١:٠٨, Charles Jenkins  wrote:
> I think it most likely I’m doing this in the wrong place. But what’s the 
> right place? Overriding NSDocument’s setFileModificationDate() would seem 
> like the best way, but the NSDocument Programming guide says messages are 
> sent to setFileURL:, setFileType: and setFileModificationDate: “if 
> appropriate,” so I’m not sure I can count on getting that message.

 I don't think that's a good spot, as it isn't explicitly connected to file 
saving. I'd try updateChangeCount: instead, and check for NSChangeCleared.

 Also, keep in mind that "Save to..." and the likes also may get used on your 
document, saving to a different file but (IIRC) leaving the original document 
dirty. Maybe I'm misremembering what they do, but all those definitely need 
testing.

-- Uli
http://stacksmith .org
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com