Is this an incorrect use of categories ?

  • Greetings list,

    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 (?)

    Any observations appreciated.

    Here are the two objects, one a Plugin API object, the other it's corresponding Rule, and following them the two categories I believe should be able to swap data between them.

    #import "RSTrixiePlugin.h"

    @interface RSReactionPlugin : RSTrixiePlugin

    @property (retain) NSString * pluginName;
    @property (retain) NSString * action;
    @property (retain) IBOutlet NSTextField * targetField;
    @property (retain) IBOutlet NSTextField * deltaField;
    @property (retain) IBOutlet NSTextField * delayField;
    @property (retain) IBOutlet NSTextField * periodField;
    @property (retain) IBOutlet NSTextField * opacityField;
    @property (retain) IBOutlet NSTextField * easingField;
    @property (retain) IBOutlet NSTextField * callbackField;

    - (BOOL) hasTargetField;
    - (BOOL) hasDeltaField;
    - (BOOL) hasDelayField;
    - (BOOL) hasPeriodField;
    - (BOOL) hasOpacityField;
    - (BOOL) hasEasingField;
    - (BOOL) hasCallbackField;

    - (void) resetForm;

    @end

    ---------------

    #import "RSAbstractRule.h"

    @interface RSReactionRule : RSAbstractRule

    @property (retain) NSString * pluginName;
    @property (retain) NSString * action;
    @property (retain) NSString * targetField;
    @property (retain) NSString * deltaField;
    @property (retain) NSString * delayField;
    @property (retain) NSString * periodField;
    @property (retain) NSString * opacityField;
    @property (retain) NSString * easingField;
    @property (retain) NSString * callbackField;

    @property (assign,setter=setHasTargetField:) BOOL hasTargetField;
    @property (assign,setter=setHasDeltaField:) BOOL hasDeltaField;
    @property (assign,setter=setHasDelayField:) BOOL hasDelayField;
    @property (assign,setter=setHasPeriodField:) BOOL hasPeriodField;
    @property (assign,setter=setHasOpacityField:) BOOL hasOpacityField;
    @property (assign,setter=setHasEasingField:) BOOL hasEasingField;
    @property (assign,setter=setHasCallbackField:) BOOL hasCallbackField;

    - (NSString*) action;
    - (void) setAction:(NSString *)aStr;
    - (NSString*) emitScript;

    @end

    ------------

    #import <RSTrixieFramework/RSTrixie.h>

    @interface RSReactionRule (RSReactionRuleFromPlugin)

    - (void) loadFromPlugin:(RSReactionPlugin*)plugin;

    @end

    #import "RSReactionRule+RSReactionRuleFromPlugin.h"

    @implementation RSReactionRule (RSReactionRuleFromPlugin)

    - (void) loadFromPlugin:(RSReactionPlugin*)plugin {

    [self setAction: plugin.action];

    if(plugin.hasTargetField) {
      [self setHasTargetField: YES];
      [self setTargetField:[plugin.targetField stringValue]];
    }
    if(plugin.hasDeltaField) {
      [self setHasDeltaField:YES];
      [self setDeltaField:[plugin.deltaField stringValue]];
    }
    if(plugin.hasDelayField) {
      [self setHasDelayField: YES];
      [self setDelayField: [plugin.delayField stringValue]];
    }
    if(plugin.hasPeriodField) {
      [self setHasPeriodField: YES];
      [self setPeriodField: [plugin.periodField stringValue]];
    }
    if(plugin.hasOpacityField) {
      [self setHasOpacityField:YES];
      [self setOpacityField:[plugin.opacityField stringValue] ];
    }
    if(plugin.hasEasingField) {
      [self setHasEasingField:YES];
      [self setEasingField:[plugin.easingField stringValue]];
    }
    if(plugin.hasCallbackField) {
      [self setHasCallbackField: YES];
      [self setCallbackField:[plugin.callbackField stringValue]];
    }
    }

    @end

    ------------

    #import <RSTrixieFramework/RSTrixie.h>

    @interface RSReactionPlugin (RSReactionPluginFromRule)

    - (void) loadFromRule: (RSReactionRule*) rule;

    @end

    #import "RSReactionPlugin+RSReactionPluginFromRule.h"

    @implementation RSReactionPlugin (RSReactionPluginFromRule)

    - (void) loadFromRule: (RSReactionRule*) rule {
    self.action = rule.action;
    if([rule hasTargetField]) [self.targetField setStringValue:rule.targetField];
    if([rule hasDeltaField]) [self.deltaField setStringValue:rule.deltaField];
    if([rule hasDelayField]) [self.delayField setStringValue:rule.delayField];
    if([rule hasPeriodField]) [self.periodField setStringValue:rule.periodField];
    if([rule hasOpacityField]) [self.opacityField setStringValue:rule.opacityField];
    if([rule hasEasingField]) [self.easingField setStringValue:rule.easingField];
    if([rule hasCallbackField]) [self.callbackField setStringValue:rule.callbackField];
    }

    @end

    ---------------

    End of message.

    Erik Stainsby.
  • On 06/07/2012, at 12:50 PM, Erik Stainsby wrote:

    > 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 (?)

    At run-time, if the target object implements the selector (whether in a category or otherwise), you won't get this message. So, the target object is either not what you think it is, or the category wasn't attached.

    If the selector is supplied by a category, then the category must have been loaded in order to be attached to the class. If that category is implemented by the plug-in, you must have loaded and linked the plug-in before calling the method, so if that's the case I'd be looking at where and how you are doing this - usually you use the methods of the NSBundle class to load your plug-in. e.g. -loadAndReturnError:

    It's not that clear from what you posted where the category is defined and implemented - in your app or in the plug-in.

    --Graham
  • Thanks for the reply Graham.

    The categories are loaded in a window controller which serves as the context for the plugins. The plugins are loaded with a convenience method from my framework, which uses NSBundle loading techniques.

    Is it sufficient that the categories be loaded in the windowController code? Or do they need to be available in the framework context in which the plugins are actually loaded from nib?  That is, my categories are being added in the app not in the framework.

    RSRuleWindowController.m:

    #import "RSRuleWindowController.h"
    #import "NSView+RSPositionView.h"
    #import "DOMElement+RSLDOMExtensions.h"

    #import "RSActionRule+RSActionRuleFromPlugin.h"
    #import "RSFilterRule+RSFilterRuleFromPlugin.h"
    #import "RSReactionRule+RSReactionRuleFromPlugin.h"

    #import "RSActionPlugin+RSActionPluginFromRule.h"
    #import "RSFilterPlugin+RSFilterPluginFromRule.h"
    #import "RSReactionPlugin+RSReactionPluginFromRule.h"

    @implementation RSRuleWindowController

    - (id)        init {
        self = [super initWithWindowNibName:@"RSRuleWindow"];
        if (self) {
      _rules = [NSMutableDictionary dictionary];

      RSTrixieLoader *loader = [[RSTrixieLoader alloc] init];

      self.actionPlugins = [loader loadPluginsWithPrefix:@"Action" ofType:@"bundle"];
      self.filterPlugins = [loader loadPluginsWithPrefix:@"Filter" ofType:@"bundle"];
      self.reactionPlugins = [loader loadPluginsWithPrefix:@"Reaction" ofType:@"bundle"];
      loader = nil;
    }
    return self;
    }

    […]

    @end

    On 2012-07-05, at 8:23 PM, Graham Cox <graham.cox...> wrote:

    >
    > On 06/07/2012, at 12:50 PM, Erik Stainsby wrote:
    >
    >> 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 (?)
    >
    >
    > At run-time, if the target object implements the selector (whether in a category or otherwise), you won't get this message. So, the target object is either not what you think it is, or the category wasn't attached.
    >
    > If the selector is supplied by a category, then the category must have been loaded in order to be attached to the class. If that category is implemented by the plug-in, you must have loaded and linked the plug-in before calling the method, so if that's the case I'd be looking at where and how you are doing this - usually you use the methods of the NSBundle class to load your plug-in. e.g. -loadAndReturnError:
    >
    > It's not that clear from what you posted where the category is defined and implemented - in your app or in the plug-in.
    >
    >
    > --Graham
    >
    >
  • On 06/07/2012, at 1:54 PM, Erik Stainsby wrote:

    > Is it sufficient that the categories be loaded in the windowController code? Or do they need to be available in the framework context in which the plugins are actually loaded from nib?  That is, my categories are being added in the app not in the framework.

    It would normally be sufficient, but I think you might be running into a load order issue.

    Is this right?: You have a class 'MyClass' defined by a plug-in, and a category 'MyClass (ExtraStuff)' defined by your app.

    If so, I don't think that will work. When your app is loaded and linked when it's launched, the category won't be attached to the class 'MyClass' because it doesn't exist. It is only loaded and linked when the plug-in is loaded, but the runtime can't retrospectively attach the category - its opportunity to do so automatically has passed. You might be able to use the low-level runtime methods to attempt to reattach the category after you have loaded the plug-ins.

    Or it might be better to rethink how you're doing this so it's not so dependent on load order.

    (Of course, I may have totally misread the situation).

    --Graham
  • On Jul 5, 2012, at 7:50 PM, Erik Stainsby <erik.stainsby...> 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?

    Are there any static libraries involved in your build process? Categories compiled into static libraries require special treatment.

    --
    Greg Parker    <gparker...>    Runtime Wrangler
  • On Jul 5, 2012, at 9:24 PM, Graham Cox <graham.cox...> wrote:
    > If so, I don't think that will work. When your app is loaded and linked when it's launched, the category won't be attached to the class 'MyClass' because it doesn't exist. It is only loaded and linked when the plug-in is loaded, but the runtime can't retrospectively attach the category - its opportunity to do so automatically has passed. You might be able to use the low-level runtime methods to attempt to reattach the category after you have loaded the plug-ins.

    This is usually not an issue because usually you get a missing symbol error from the linker if you try to arrange your code this way. (The category implementation has a C symbol reference to the class's implementation.)

    --
    Greg Parker    <gparker...>    Runtime Wrangler
  • On 2012-07-06, at 12:46 PM, Greg Parker <gparker...> wrote:

    > On Jul 5, 2012, at 7:50 PM, Erik Stainsby <erik.stainsby...> 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    <gparker...>    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
  • On Jul 6, 2012, at 4:48 PM, Erik Stainsby <erik.stainsby...> wrote:
    > 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

    How is -[RSReactionRule setAction:] implemented? It wasn't in your quoted categories.

    --
    Greg Parker    <gparker...>    Runtime Wrangler
  • 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 <gparker...> wrote:
    >
    >> On Jul 5, 2012, at 7:50 PM, Erik Stainsby <erik.stainsby...> 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    <gparker...>    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
  • On 2012-07-06, at 5:11 PM, Greg Parker <gparker...> wrote:

    > On Jul 6, 2012, at 4:48 PM, Erik Stainsby <erik.stainsby...> wrote:
    >> 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
    >
    > How is -[RSReactionRule setAction:] implemented? It wasn't in your quoted categories.

    Actually it was part of my first post: it is declared

    @property (retain) action;
    @synthesize action=_action;

    ~ as implemented in the RSReactionRule.  It is invoked in the category, as:  [self setAction: plugin.action];

    > --
    > Greg Parker    <gparker...>    Runtime Wrangler
    >
    >
  • On 2012-07-06, at 5:28 PM, Erik Stainsby <erik.stainsby...> wrote:

    > On 2012-07-06, at 5:11 PM, Greg Parker <gparker...> wrote:
    >
    >> On Jul 6, 2012, at 4:48 PM, Erik Stainsby <erik.stainsby...> wrote:
    >>> 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
    >>
    >> How is -[RSReactionRule setAction:] implemented? It wasn't in your quoted categories.
    >
    > Actually it was part of my first post: it is declared
    >
    > @property (retain) action;

    Check that:
    @property (retain) NSString * action;

    > @synthesize action=_action;
    >
    > ~ as implemented in the RSReactionRule.  It is invoked in the category, as:  [self setAction: plugin.action];
    >
    >
    >
    >
    >
    >> --
    >> Greg Parker    <gparker...>    Runtime Wrangler
    >>
    >>
    >
  • On 2012-07-06, at 5:13 PM, Alex Zavatone <zav...> wrote:

    > OK.  I'm not sure what I ran into is related, but maybe it is.
    >
    > 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.

    The selector name is reported in the error message, and the method is declared as a @property/@synthesize so I have no reason to doubt that they match up.

    I have in troubleshooting this hand coded the setter/getter and removed the property decl. With nil difference in the result. Still not recognized.  Which is why I started to think about scope issues.

    >
    > On Jul 6, 2012, at 7:48 PM, Erik Stainsby wrote:
    >
    >>
    >>
    >> On 2012-07-06, at 12:46 PM, Greg Parker <gparker...> wrote:
    >>
    >>> On Jul 5, 2012, at 7:50 PM, Erik Stainsby <erik.stainsby...> 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    <gparker...>    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
    >
previous month july 2012 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today