Re: Is this an incorrect use of categories ?
Re: Is this an incorrect use of categories ?
- Subject: Re: Is this an incorrect use of categories ?
- From: Alex Zavatone <email@hidden>
- Date: Fri, 06 Jul 2012 20:13:18 -0400
OK. I'm not sure what I ran into is related, but maybe it is.
I was calling performSegueWithIdentifier on a storyboard action and passing in the exact segue name. Instant SIGABRT. Checked the wiring up of all outlets and such. Everything was fine.
I did have two storyboards, one in French, the other in English. Even though everything was wired up properly to the right controller, this still happened all the time.
Deleting and readding the segue from VC to VC and naming it properly didn't change things.
Simply duplicating the scene, adding a new segue, naming it properly and wiring it exactly as had been done before got the segue working in the English storyboard.
Comparing it and all the outlets and segues to the French, it was exactly the same, but the French version still crashed on the segue. Performing the same procedure on the French storyboard got it working.
As far as I can tell, what was happening was that Xcode's GUI was indicating that everything was legit, but it wasn't and in the case of sending an unimplemented method to an object, Xcode simply SIGABRTs without telling you which object and which method it thought was being executed.
So, back to your "unrecognized selector sent to instance whatever". As far as I can tell, we trust that the GUI of our dev tools are being accurate. It appears that is not always the case.
In my case, I swore and checked that the right message (segue name identifier) was being used in performSegueWithIdentifier. It was. Xcode thought differently.
Sometimes it pays to doubt the accuracy of what your dev tools tell you.
If you can isolate the line of code before the crash, can you check and NSLog the string value of the selector being sent and see if it matches the selectors on the object?
GL.
On Jul 6, 2012, at 7:48 PM, Erik Stainsby wrote:
>
>
> On 2012-07-06, at 12:46 PM, Greg Parker <email@hidden> wrote:
>
>> On Jul 5, 2012, at 7:50 PM, Erik Stainsby <email@hidden> wrote:
>>> My project employs a framework which loads several plugins. When the user interacts with these plugins s/he generates an intermediate abstraction of the plugin contents which I refer to as a rule. The rule abstraction exists to facilitate round-tripping back to the plugin of origin or onward to the rendered product.
>>>
>>> I am currently stuck in the stage of migrating the data from the plugin to a newly created rule instance. I hit on the notion of using categories to shuffle the values from the plugin instance to the rule instance and vice versa. Two small dedicated categories for each plugin family (I have three families at the moment). Seems a manageable scheme. However, I am getting an "unrecognized selector sent to instance 0xyaddayadda" when I try to run this. I know the selector does exist, so I must have a scoping issue (?)
>>
>> What exactly is the unrecognized selector message you get?
>>
>
>
> 2012-07-04 20:43:50.180 Trixie[422:303] -[RSLocatorView requestPopover:]- [0098]
> 2012-07-04 20:44:02.980 Trixie[422:303] -[RSReactionRule(RSReactionRuleFromPlugin) loadFromPlugin:]- [0015] plugin.action: addClass
> 2012-07-04 20:44:02.981 Trixie[422:303] -[RSReactionRule setAction:]: unrecognized selector sent to instance 0x101833fe0
> 2012-07-04 20:44:02.981 Trixie[422:303] -[RSReactionRule setAction:]: unrecognized selector sent to instance 0x101833fe0
> 2012-07-04 20:44:02.983 Trixie[422:303] (
> 0 CoreFoundation 0x00007fff90996716 __exceptionPreprocess + 198
> 1 libobjc.A.dylib 0x00007fff8c97c470 objc_exception_throw + 43
> 2 CoreFoundation 0x00007fff90a2cd5a -[NSObject(NSObject) doesNotRecognizeSelector:] + 186
> 3 CoreFoundation 0x00007fff90984c3e ___forwarding___ + 414
> 4 CoreFoundation 0x00007fff90984a28 _CF_forwarding_prep_0 + 232
> 5 Trixie 0x000000010000cf81 -[RSReactionRule(RSReactionRuleFromPlugin) loadFromPlugin:] + 177
> 6 Trixie 0x000000010000b6d9 -[RSRuleWindowController addRuleToStore:] + 249
> 7 AppKit 0x00007fff91589599 -[NSApplication sendAction:to:from:] + 342
> 8 AppKit 0x00007fff915893f7 -[NSControl sendAction:to:] + 85
> 9 AppKit 0x00007fff9158932b -[NSCell _sendActionFrom:] + 138
> 10 AppKit 0x00007fff91587813 -[NSCell trackMouse:inRect:ofView:untilMouseUp:] + 1855
> 11 AppKit 0x00007fff91587061 -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] + 504
> 12 AppKit 0x00007fff915867dc -[NSControl mouseDown:] + 820
> 13 AppKit 0x00007fff9157e13e -[NSWindow sendEvent:] + 6853
> 14 AppKit 0x00007fff9157a274 -[NSApplication sendEvent:] + 5761
> 15 AppKit 0x00007fff9148feaa -[NSApplication run] + 636
> 16 AppKit 0x00007fff91434886 NSApplicationMain + 869
> 17 Trixie 0x0000000100001b12 main + 34
> 18 libdyld.dylib 0x00007fff8f9e27e1 start + 0
> )
>
>
>
>> Are there any static libraries involved in your build process? Categories compiled into static libraries require special treatment.
>> --
>> Greg Parker email@hidden Runtime Wrangler
>>
>
> I am only using the home-built loader framework as mentioned. No other external-to-Cocoa libs.
>
> I opted to use categories in this case to avoid having to directly modify my framework. But if there is as Graham suggested a load order issue, I might be better off implementing the method natively in the framework. I pretty much have the code already in the categories. :D
>
> Erik
>
>
>
> _______________________________________________
>
> 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
_______________________________________________
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