Re: Trouble with "self" in Carbon and Cocoa
Re: Trouble with "self" in Carbon and Cocoa
- Subject: Re: Trouble with "self" in Carbon and Cocoa
- From: Bill Cheeseman <email@hidden>
- Date: Mon, 24 Mar 2003 14:50:06 -0500
on 03-03-24 1:51 PM, Vince DeMarco at email@hidden wrote:
>
On Saturday, March 22, 2003, at 2:23 AM, Jeffrey Mattox wrote:
>
> I want to understand why the compiler is complaining. What must I to
>
> do to get "self" to work in HotKeyHandler()?
I think we gave you lots of cures but no explanation about why the compiler
is complaining.
This is why the compiler complains about a reference to self in a C
function: The self variable is a creature of Cocoa. It is only recognized
within Cocoa methods, where it refers to the receiver (that is, to an object
instantiated from the class that declares the method). Since your callback
function is a C function, not a Cocoa method, it has no idea that the
receiver exists, nor even what an object is, let alone what the word "self"
refers to. Self is an undefined variable in the context of a C function. So,
when you need to refer to the Cocoa object in which a C function is
declared, from within the function (which you often do), you have to provide
that information to the function in some fashion.
If you have declared a global variable referring to the class in which the
function is declared, you can use that. Or if you have a pre-made Cocoa
global variable like NSApp, you can use that, on the same theory. C
functions know about global variables, just as Cocoa methods do.
This is one of the consequences of the fact that Objective-C is a superset
of C. Things that exist in the C language, such as global variables, work
both in Cocoa objects and in C functions. Things that are part of the
Objective-C extensions to C, such as self, are not known to C functions, but
only to Objective-C methods.
Personally, I prefer to pass self through a userInfo parameter to a C
function, if the function has one. Just pass self to the userInfo parameter
in the registration function, then pull it back out of the userInfo
parameter in the associated callback function.
You can do some pretty funky things with this technique. For example,
suppose you're writing a Cocoa wrapper for a C API that employs a callback
function. You can implement the callback function in your Cocoa wrapper,
instead of requiring the wrapper's clients to write the C callback function
themselves. The clients can implement their own callbacks as Cocoa methods,
assuming you provide them with the signature required for a Cocoa callback
method that your wrapper will recognize. The wrapper registers self in the
userInfo parameter of its registration function; the wrapper pulls self out
of the userInfo parameter of its callback function; and the callback
function in turn invokes a Cocoa callback method in the client using
NSInvocation, passing self along in one of the invocation parameters. When
it's all over, this gives the Cocoa callback method in the client access to
the original self, namely, the Cocoa object wrapping the C API.
There are many places in the Cocoa frameworks where you can implement Cocoa
callback methods. The documentation always tells you what the callback
method's signature must be. I believe many of these use the technique just
described.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.