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 <gpar...@apple.com> wrote: > >> On Jul 5, 2012, at 7:50 PM, Erik Stainsby <erik.stain...@roaringsky.ca> >> 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 gpar...@apple.com 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 (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
