Re: NSTextField "Discard Change"

[Richard Charles]

I have a custom NSNumberFormatter which does validation. If I bind the text 
field using NSValueBinding then when validation fails an alert panel will 
automatically appear. However it is the binding machinery that brings up the 
alert panel. Apple integrates bindings with user interface elements using a ton 
of private classes.

If you have a custom binding then the primary method at your disposal is 
bind:toObject:withKeyPath:options: which for a custom binding has no 
integration user interface elements. The binding is only one-way, model changes 
are pushed to the view but the view must manually push changes back to the 
model. So in addition to writing code to push view changes to the model you 
must also write code to present an error alert panel and discard a change.

--Richard Charles

> On May 6, 2019, at 7:49 AM, Keary Suska  wrote:
> 
> IIRC, you get this behavior automatically when validating with a formatter, 
> so applying a custom NSNumberFormatter subclass might be more canonical and 
> less kludgey.
> 
> HTH,
> 
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
> 
>> On May 6, 2019, at 5:33 AM, Richard Charles  wrote:
>> 
>> Thank you Quincey, Sean, Gary and Alex for your comments and suggestions.
>> 
>> To recap I have a NSTextField subclass bound to an array controller using a 
>> derived value binding. The user selects one or more objects in a graphic 
>> view. Object properties are shown in an inspector containing the text field.
>> 
>> A custom derived value binding is needed because object properties are 
>> floating point values with limited precision. Values that are close to equal 
>> are considered equal from the user's point of view.
>> 
>> When garbage is entered into a text field and the user presses the return 
>> key an alert panel is presented as a sheet attached to the window. The user 
>> can choose "Discard Change" or "OK”.
>> 
>> Because a custom binding is used code must be added to present the error and 
>> recover from the error. My text field subclass implements the 
>> NSErrorRecoveryAttempting informal protocol.
>> 
>> My original discard change code did not work.
>> 
>> - (void)attemptRecoveryFromError:(NSError *)error
>> optionIndex:(NSUInteger)recoveryOptionIndex
>>delegate:(id)delegate
>>  didRecoverSelector:(SEL)didRecoverSelector
>> contextInfo:(void *)contextInfo
>> {
>>// Discard Change
>>if (recoveryOptionIndex == 1) {
>>[self abortEditing]; // does not work
>>}
>> }
>> 
>> Here is a solution that works well.
>> 
>> - (void)attemptRecoveryFromError:(NSError *)error
>> optionIndex:(NSUInteger)recoveryOptionIndex
>>delegate:(id)delegate
>>  didRecoverSelector:(SEL)didRecoverSelector
>> contextInfo:(void *)contextInfo
>> {
>>// Discard Change
>>if (recoveryOptionIndex == 1) {
>>// Revert display back to original value.
>>[self abortEditing];
>>[self setObjectValue:self.cachedObjectValue];
>>[self.window makeFirstResponder:self];
>>}
>> }
>> 
>> The abortEditing message is needed otherwise the binding will push the 
>> updated cached object value to the model.
>> 
>> --Richard Charles

___

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: NSTextField "Discard Change"

[Keary Suska]

IIRC, you get this behavior automatically when validating with a formatter, so 
applying a custom NSNumberFormatter subclass might be more canonical and less 
kludgey.

HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"

> On May 6, 2019, at 5:33 AM, Richard Charles  wrote:
> 
> Thank you Quincey, Sean, Gary and Alex for your comments and suggestions.
> 
> To recap I have a NSTextField subclass bound to an array controller using a 
> derived value binding. The user selects one or more objects in a graphic 
> view. Object properties are shown in an inspector containing the text field.
> 
> A custom derived value binding is needed because object properties are 
> floating point values with limited precision. Values that are close to equal 
> are considered equal from the user's point of view.
> 
> When garbage is entered into a text field and the user presses the return key 
> an alert panel is presented as a sheet attached to the window. The user can 
> choose "Discard Change" or "OK”.
> 
> Because a custom binding is used code must be added to present the error and 
> recover from the error. My text field subclass implements the 
> NSErrorRecoveryAttempting informal protocol.
> 
> My original discard change code did not work.
> 
> - (void)attemptRecoveryFromError:(NSError *)error
>  optionIndex:(NSUInteger)recoveryOptionIndex
> delegate:(id)delegate
>   didRecoverSelector:(SEL)didRecoverSelector
>  contextInfo:(void *)contextInfo
> {
> // Discard Change
> if (recoveryOptionIndex == 1) {
> [self abortEditing]; // does not work
> }
> }
> 
> Here is a solution that works well.
> 
> - (void)attemptRecoveryFromError:(NSError *)error
>  optionIndex:(NSUInteger)recoveryOptionIndex
> delegate:(id)delegate
>   didRecoverSelector:(SEL)didRecoverSelector
>  contextInfo:(void *)contextInfo
> {
> // Discard Change
> if (recoveryOptionIndex == 1) {
> // Revert display back to original value.
> [self abortEditing];
> [self setObjectValue:self.cachedObjectValue];
> [self.window makeFirstResponder:self];
> }
> }
> 
> The abortEditing message is needed otherwise the binding will push the 
> updated cached object value to the model.
> 
> --Richard Charles
> 
> ___
> 
> 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/cocoa-dev%40esoteritech.com
> 
> This email sent to cocoa-...@esoteritech.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: NSTextField "Discard Change"

[Richard Charles]

Thank you Quincey, Sean, Gary and Alex for your comments and suggestions.

To recap I have a NSTextField subclass bound to an array controller using a 
derived value binding. The user selects one or more objects in a graphic view. 
Object properties are shown in an inspector containing the text field.

A custom derived value binding is needed because object properties are floating 
point values with limited precision. Values that are close to equal are 
considered equal from the user's point of view.

When garbage is entered into a text field and the user presses the return key 
an alert panel is presented as a sheet attached to the window. The user can 
choose "Discard Change" or "OK”.

Because a custom binding is used code must be added to present the error and 
recover from the error. My text field subclass implements the 
NSErrorRecoveryAttempting informal protocol.

My original discard change code did not work.

- (void)attemptRecoveryFromError:(NSError *)error
  optionIndex:(NSUInteger)recoveryOptionIndex
 delegate:(id)delegate
   didRecoverSelector:(SEL)didRecoverSelector
  contextInfo:(void *)contextInfo
{
 // Discard Change
 if (recoveryOptionIndex == 1) {
 [self abortEditing]; // does not work
 }
}

Here is a solution that works well.

- (void)attemptRecoveryFromError:(NSError *)error
  optionIndex:(NSUInteger)recoveryOptionIndex
 delegate:(id)delegate
   didRecoverSelector:(SEL)didRecoverSelector
  contextInfo:(void *)contextInfo
{
 // Discard Change
 if (recoveryOptionIndex == 1) {
 // Revert display back to original value.
 [self abortEditing];
 [self setObjectValue:self.cachedObjectValue];
 [self.window makeFirstResponder:self];
 }
}

The abortEditing message is needed otherwise the binding will push the updated 
cached object value to the model.

--Richard Charles

___

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: NSTextField "Discard Change"

[Alex Zavatone]

It looks like time to subclass or extend and add the functionality you need.

Sent from my iPhone

On Apr 27, 2019, at 7:26 PM, Richard Charles  wrote:

>> On Apr 7, 2019, at 11:03 AM, Quincey Morris 
>>  wrote:
>> 
>>> On Apr 5, 2019, at 20:55 , Richard Charles  wrote:
>>> 
>>> Sending the text field an abortEditing message does not work. How can 
>>> changes to the text field be discarded?
>> 
>> Caveat: I don’t know the answer to what you’re asking, but I suspect you may 
>> be asking the wrong question.
>> 
>> First of all, what does “does not work” mean?
> 
> 
> Sending the text field an abortEditing message results in no changes to the 
> text field. Nothing happens.
> 
> 
>> Second, looking at the documentation here:
>> 
>> https://developer.apple.com/documentation/appkit/nscontrol
>> 
>> the “abortEditing” method is listed under “Managing the Field Editor”. I 
>> suspect it’s actually used internally to manage the relationship between the 
>> text field’s cell and the field editor, and not to manage the editing state 
>> of the control as a while. This method is probably just the wrong hammer for 
>> this nail.
>> 
>> Third, what I think you’re looking for is “discardEditing”, which is a part 
>> of the NSEditor protocol, to which NSTextField conforms. However, I’m not 
>> entirely sure about timing, whether it’s reasonable to invoke in response to 
>> “attemptRecoveryFromError:…”. But maybe.
> 
> 
> According to macOS 10.13 documentation (NSKeyValueBinding.h) discardEditing 
> is implemented by controllers, CoreData's managed object contexts, and user 
> interface elements.
> 
> However upon searching the macOS SDK, discardEditing is only implemented by 
> by NSController and NSViewController. It is not implemented by any user 
> interface elements. Testing has confirmed that NSTextField does not implement 
> discardEditing.
> 
> Sending the array controller bound to the text field a discardEditing message 
> does’t work either. Nothing happens. Switching back to a standard cocoa value 
> binding and placing symbolic breakpoints on -[NSController discardEditing] 
> and -[NSArrayController discardEditing] shows that when the user clicks 
> "Discard Change" in the alert panel, discardEditing is never called. So the 
> cocoa frameworks are using some other means to discard the change from the 
> text field.
> 
> 
>> Note that the documentation for NSEditor shows its methods as deprecated:
>> 
>> https://developer.apple.com/documentation/appkit/view_management/nseditor
>> 
>> I believe this is a documentation error. At some point, NSEditor was 
>> converted from an informal protocol to a formal protocol (so it would 
>> translate into Swift properly), and that causes this error in the 
>> documentation. If you look at the actual header file (NSKeyValueBinding.h), 
>> you can see that the formal NSEditor protocol has no deprecations:
>> 
>>> @protocol NSEditor 
>>> 
>>> - (void)discardEditing;// …
>>> - (BOOL)commitEditing;// …
>> 
>> as well as the deprecations of the information protocol methods:
>> 
>>> @interface NSObject (NSEditor)
>>> - (void)discardEditing NS_DEPRECATED_MAC(10_0, API_TO_BE_DEPRECATED, "This 
>>> is now a method of the NSEditor protocol.");
>>> - (BOOL)commitEditing NS_DEPRECATED_MAC(10_0, API_TO_BE_DEPRECATED, "This 
>>> is now a method of the NSEditor protocol.”);
> 
> 
> In summary testing has shown that discardEditing messages are sent to 
> controllers which are bound to a text field during normal operation. But when 
> the user chooses "Discard Change" in an alert panel a discardEditing message 
> is never sent. The frameworks are using some other means to discard the 
> change from the text field.
> 
> So this all is a bit of a mystery how to programmatically discard a change 
> from a text field bound to an array controller.
> 
> --Richard Charles
> 
> ___
> 
> 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/zav%40mac.com
> 
> This email sent to z...@mac.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: NSTextField "Discard Change"

[Quincey Morris]

On Apr 27, 2019, at 10:26 , Richard Charles  wrote:
> 
> Contrary to the documentation NSTextField does not support the NSEditor 
> protocol.

Well, I apologize for not researching my answer better when I answered before. 
However, be careful of what you assume from the documentation. NSTextField may 
not conform to the new *format* NSEditor protocol, but that doesn’t stop it 
from conforming to the informal protocol, if that’s what it always did.

In that regard, you can see this discussed here:

https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaBindings/Concepts/HowDoBindingsWork.html#//apple_ref/doc/uid/20002373-200965
 


That’s a very old document (Leopard era), and it says this:

> NSEditor/NSEditorRegistration
> 
> Together the NSEditorRegistration and NSEditor protocols allow views to 
> notify a controller that an edit is underway and to ensure that any pending 
> edits are committed as and when necessary.
> 
> The NSEditorRegistration informal protocol is implemented by controllers to 
> provide an interface for a view—the editor—to inform the controller when it 
> has uncommitted changes. When an edit is initiated, the view sends the 
> controller an objectDidBeginEditing: message. When the edit is complete (for 
> example when the user presses Return) the view sends an objectDidEndEditing: 
> message.
> 
> The controller is responsible for tracking which editors have uncommitted 
> changes and requesting that they commit or discard any pending edits when 
> appropriate—for example, if the user closes the window or quits the 
> application. The request takes the form of a commitEditing or 
> discardEditingmessage, defined by the NSEditor informal protocol. 
> NSController provides an implementation of this protocol, ***as do the 
> Application Kit user interface elements that support binding***.

(my emphasis in that last sentence)

I can also confirm, from having relied on this behavior for a decade or more, 
binding a text field to a NSObjectController *does* result in the text field 
committing editing when the controller asks it to.

In general, the NSObjectController, which implements both NSEditorRegistration 
and NSEditor, presents itself as a single editor to its “owning” controller, 
such as a NSDocument or NSViewController — but unfortunately not 
NSWindowController. When told to commit or discard its edits, the 
NSObjectController translates that into commit or discard messages for the 
NSEditor objects it owns).

On Apr 27, 2019, at 10:26 , Richard Charles  wrote:
> 
> Sending the array controller bound to the text field a discardEditing message 
> does’t work either.

I’m a bit confused by this. Why would you have a text field bound to an array 
controller? Are you talking about text fields in table view cells, where the 
table content is bound to an array controller? That’s a more complex scenario.

Describing these scenarios in words doesn’t seem to shedding much light on the 
subject. Maybe this is something you could put into a test project?
___

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: NSTextField "Discard Change"

[Gary L. Wade]

From what you’ve described and shown, your expectations for discardEditing are 
not correct.  The method discardEditing is a method you implement, typically on 
your view controller that owns/manages your text field.  There’s not really any 
good sample source using discardEditing I could find to point you to, but this 
one seems to give as best as can be.

https://sourceforge.net/p/skim-app/mailman/message/22781851/ 


It sounds like you want to fill the field with the previous value that was in 
there, and while you could do it in a text field subclass, you’re probably 
better off managing that from its controller.  By the time your sheet shows up, 
your text field is no longer performing any editing since it’s no longer the 
first responder.
--
Gary L. Wade
http://www.garywade.com/ 

> On Apr 27, 2019, at 10:26 AM, Richard Charles  wrote:
> 
>> On Apr 9, 2019, at 9:40 AM, Sean McBride  wrote:
>> 
>> NSTextField in fact does *not* support commitEditing/discardEditing, as per 
>> this a decade ago:
>> 
>> 
>> 
>> I don't think I ever did find another solution to my problem other than to 
>> use an NSObjectController.
> 
> 
> My testing shows you are correct. Contrary to the documentation NSTextField 
> does not support the NSEditor protocol. No App Kit user interface elements 
> that I can find support this protocol. It is only supported by NSController 
> and NSViewController.
> 
> --Richard Charles

___

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: NSTextField "Discard Change"

[Richard Charles]

> On Apr 9, 2019, at 9:40 AM, Sean McBride  wrote:
> 
> NSTextField in fact does *not* support commitEditing/discardEditing, as per 
> this a decade ago:
> 
> 
> 
> I don't think I ever did find another solution to my problem other than to 
> use an NSObjectController.


My testing shows you are correct. Contrary to the documentation NSTextField 
does not support the NSEditor protocol. No App Kit user interface elements that 
I can find support this protocol. It is only supported by NSController and 
NSViewController.

--Richard Charles

___

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: NSTextField "Discard Change"

[Richard Charles]

> On Apr 7, 2019, at 11:03 AM, Quincey Morris 
>  wrote:
> 
>> On Apr 5, 2019, at 20:55 , Richard Charles  wrote:
>> 
>> Sending the text field an abortEditing message does not work. How can 
>> changes to the text field be discarded?
> 
> Caveat: I don’t know the answer to what you’re asking, but I suspect you may 
> be asking the wrong question.
> 
> First of all, what does “does not work” mean?


Sending the text field an abortEditing message results in no changes to the 
text field. Nothing happens.


> Second, looking at the documentation here:
> 
> https://developer.apple.com/documentation/appkit/nscontrol
> 
> the “abortEditing” method is listed under “Managing the Field Editor”. I 
> suspect it’s actually used internally to manage the relationship between the 
> text field’s cell and the field editor, and not to manage the editing state 
> of the control as a while. This method is probably just the wrong hammer for 
> this nail.
> 
> Third, what I think you’re looking for is “discardEditing”, which is a part 
> of the NSEditor protocol, to which NSTextField conforms. However, I’m not 
> entirely sure about timing, whether it’s reasonable to invoke in response to 
> “attemptRecoveryFromError:…”. But maybe.


According to macOS 10.13 documentation (NSKeyValueBinding.h) discardEditing is 
implemented by controllers, CoreData's managed object contexts, and user 
interface elements.

However upon searching the macOS SDK, discardEditing is only implemented by by 
NSController and NSViewController. It is not implemented by any user interface 
elements. Testing has confirmed that NSTextField does not implement 
discardEditing.

Sending the array controller bound to the text field a discardEditing message 
does’t work either. Nothing happens. Switching back to a standard cocoa value 
binding and placing symbolic breakpoints on -[NSController discardEditing] and 
-[NSArrayController discardEditing] shows that when the user clicks "Discard 
Change" in the alert panel, discardEditing is never called. So the cocoa 
frameworks are using some other means to discard the change from the text field.


> Note that the documentation for NSEditor shows its methods as deprecated:
> 
> https://developer.apple.com/documentation/appkit/view_management/nseditor
> 
> I believe this is a documentation error. At some point, NSEditor was 
> converted from an informal protocol to a formal protocol (so it would 
> translate into Swift properly), and that causes this error in the 
> documentation. If you look at the actual header file (NSKeyValueBinding.h), 
> you can see that the formal NSEditor protocol has no deprecations:
> 
>> @protocol NSEditor 
>> 
>> - (void)discardEditing;// …
>> - (BOOL)commitEditing;// …
> 
> as well as the deprecations of the information protocol methods:
> 
>> @interface NSObject (NSEditor)
>> - (void)discardEditing NS_DEPRECATED_MAC(10_0, API_TO_BE_DEPRECATED, "This 
>> is now a method of the NSEditor protocol.");
>> - (BOOL)commitEditing NS_DEPRECATED_MAC(10_0, API_TO_BE_DEPRECATED, "This is 
>> now a method of the NSEditor protocol.”);


In summary testing has shown that discardEditing messages are sent to 
controllers which are bound to a text field during normal operation. But when 
the user chooses "Discard Change" in an alert panel a discardEditing message is 
never sent. The frameworks are using some other means to discard the change 
from the text field.

So this all is a bit of a mystery how to programmatically discard a change from 
a text field bound to an array controller.

--Richard Charles

___

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: NSTextField "Discard Change"

[Sean McBride]

On Sun, 7 Apr 2019 10:03:45 -0700, Quincey Morris said:

>Third, what I think you’re looking for is “discardEditing”, which is a
>part of the NSEditor protocol, to which NSTextField conforms.

A timely thread, as I'm investigating something quite similar, and was 
searching my email for 'commitEditing'.

NSTextField in fact does *not* support commitEditing/discardEditing, as per 
this a decade ago:



I don't think I ever did find another solution to my problem other than to use 
an NSObjectController.

In my case, I'm wanting to commitEditing on a text field in the action method 
of a push button that consults the text field's value.

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada
___

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: NSTextField "Discard Change"

[Richard Charles]

Quincey, thanks so much for your insight. Unfortunately I will be gone for the 
next several weeks. I thought I would be able to tackle this problem before I 
left but now I have run out of time. I will be able to look more carefully at 
your comments when I get back. Thanks again.

--Richard Charles

___

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: NSTextField "Discard Change"

[Quincey Morris]

On Apr 5, 2019, at 20:55 , Richard Charles  wrote:
> 
> Sending the text field an abortEditing message does not work. How can changes 
> to the text field be discarded?

Caveat: I don’t know the answer to what you’re asking, but I suspect you may be 
asking the wrong question.

First of all, what does “does not work” mean?

Second, looking at the documentation here:

https://developer.apple.com/documentation/appkit/nscontrol 


the “abortEditing” method is listed under “Managing the Field Editor”. I 
suspect it’s actually used internally to manage the relationship between the 
text field’s cell and the field editor, and not to manage the editing state of 
the control as a while. This method is probably just the wrong hammer for this 
nail.

Third, what I think you’re looking for is “discardEditing”, which is a part of 
the NSEditor protocol, to which NSTextField conforms. However, I’m not entirely 
sure about timing, whether it’s reasonable to invoke in response to 
“attemptRecoveryFromError:…”. But maybe.

Note that the documentation for NSEditor shows its methods as deprecated:

https://developer.apple.com/documentation/appkit/view_management/nseditor 


I believe this is a documentation error. At some point, NSEditor was converted 
from an informal protocol to a formal protocol (so it would translate into 
Swift properly), and that causes this error in the documentation. If you look 
at the actual header file (NSKeyValueBinding.h), you can see that the formal 
NSEditor protocol has no deprecations:

> @protocol NSEditor 
> 
> - (void)discardEditing;// …
> - (BOOL)commitEditing;// …


as well as the deprecations of the information protocol methods:

> @interface NSObject (NSEditor)
> - (void)discardEditing NS_DEPRECATED_MAC(10_0, API_TO_BE_DEPRECATED, "This is 
> now a method of the NSEditor protocol.");
> - (BOOL)commitEditing NS_DEPRECATED_MAC(10_0, API_TO_BE_DEPRECATED, "This is 
> now a method of the NSEditor protocol.");







___

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