Re: Preserving undo actions on deleted targets
Re: Preserving undo actions on deleted targets
- Subject: Re: Preserving undo actions on deleted targets
- From: Graham Cox <email@hidden>
- Date: Fri, 31 Jan 2014 13:15:52 +1100
On 31 Jan 2014, at 12:57 pm, Quincey Morris <email@hidden> wrote:
> On Jan 30, 2014, at 17:42 , Graham Cox <email@hidden> wrote:
>
>> - (BOOL) respondsToSelector:(SEL) aSelector
>> {
>> if( aSelector == @selector(_processEndOfEventNotification:))
>> return YES;
>> ... [other code]
>>
>> }
>
> Shouldn’t this return NO for that selector? The NSObject documentation didn’t show this as part of the ‘forwardInvocation:” process. In fact, I wouldn’t be surprised if returning YES *disables* the ‘forwardInvocation:’ path.
>
I don't think it should be NO. In other cases where I've used the forwarding mechanism, I return YES if I can forward to another object, and that works just fine.
The documentation states:
"Note that if the receiver is able to forward aSelector messages to another object, it will be able to respond to the message, albeit indirectly, even though this method returns NO."
That implies that it doesn't actually matter what you return. To check anyway, I changed it to NO and get the same result (unrecognised selector exception).
Setting breakpoints on my forwarding code, it's never called. I'm a bit puzzled by this. So far, only the stub method approach seems to work.
> Incidentally, I originally envisaged that you would use NSStringFromSelector, rather than using @selector. Since, we’re hypothesizing, there’s an automated verification tool involved in the approval process, it might be that the mere presence of a private @selector compiled into your executable might be grounds for rejection.
>
I usually do selector comparisons using == and @selector(...). I do that a fair bit, so if it's wrong, I need to know. Aren't these just comparing the addresses of C strings in a big global table?
It's hard to know what the automated tool does. All I can say for sure is that I've never been rejected for this particular usage. I have fallen foul of using other private API once upon a time in other places, so it's not that the code hasn't been run through the tool. In that case I was calling a private method, not just stubbing one out as here.
I believe this usage is safe (for now), but certainly if a cleaner solution can be found that would be great, because I know a few people are using this code and I do too, and would like to continue doing so. The thought of going back to opaque NSUndoManager gives me the willies.
--Graham
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden