Re: "Selector not recognized" for existing selector : how is this possible??
Re: "Selector not recognized" for existing selector : how is this possible??
- Subject: Re: "Selector not recognized" for existing selector : how is this possible??
- From: "Mark Munz (DevList)" <email@hidden>
- Date: Fri, 20 May 2005 18:16:04 -0500
Jonathan,
That answer sparked something with a problem I am having with my Obj-
C Automator Actions.
I have several actions and each uses a utility class.
@interface CleanerLibrary : NSObject
{
NSDictionary* cleanerLists;
}
-(NSString*)cleanPlainText:(NSString*)text withCleaner:(NSString*)
cleanerName;
@end
I started getting "selector not recognized" errors as well and I'm
now suspecting that some sort of name collisions is causing a problem
(even though they are all the same classes and have the same
methods). This seems to happen only in non-Debug, but there are
multiple actions which include this class in in each of the bundles.
I even tried making them class methods vs. having a shared instance
setup, but it still failed. I don't think the name is likely clashing
with the application (Automator),although I'm wondering if the
classes are clashing with each other.
What's the correct way to deal with this type of situation
(essentially Cocoa plug-ins)?
Do I need to create a framework? How does that solve the problem?
Is the answer to use regular old C functions and store the data in a
static var?
Or is there a better way..
Any help is greatly appreciated.
Mark Munz
On May 20, 2005, at 10:15 AM, Greg Parker wrote:
Jonathan del Strother wrote:
My GasLight plugin works fine for most people, but it certain
cases it
crashes, complaining of the following:
-[Controller initWithVisData:]: selector not recognized [self =
0x11fea00]
Now...the initWithVisData method clearly exists, because it works
fine
on most people's machines, it's in the same file as the above
function,
declare in a header file,and so on...
You may be seeing a duplicate class name collision. Your code is an
iTunes plugin, and it's using the rather generic class name
"Controller".
If some other plugin or iTunes itself also defines a class named
"Controller", there will be a conflict and one of the classes will
be ignored. If some other class called "Controller" wins, it probably
won't have a -initWithVisData: method like yours.
When the Objective-C runtime detects a collision, it prints an error
message, something like "Both Foo.framework and Bar.framework have
implementations of class Controller. Using implementation from
Foo.framework". Have your users look for that message in console.log
or system.log when the plugin fails.
In general, a plugin should use a unique prefix for all of its
classes, because all Objective-C classes live in a single global
namespace. A discussion of class name collisions in preference panes:
http://developer.apple.com/documentation/UserExperience/Conceptual/
PreferencePanes/Tasks/Conflicts.html#//apple_ref/doc/uid/20000706
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40unmarked.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden