Hi Charles / Daniel,
Thanks for the tips. That clears a lot of things up. It's a shame that I
can't pass in an object method to an external callback, but I guess it's the
only safe way to implement callbacks without the risk of the object
disappearing. Or is it just intrinsic to the nature of external callbacks,
now I think about it? i.e. You'd always use a reference parameter to refer
to the object, even in C.
My problem is that I have no control over the format of the callbacks, and
this is where it gets tricky. So for one type of controller, the callback
format is such that the unique identifier of the controller is the second
member of a struct passed in the first parameter of the callback. For
another type of controller, the identifer of the controller is the first
parameter itself. And it could be that two different types of controller
have their own "unique ID" values in the same range, so I wouldn't be able
to definitively tell them apart from the callback itself.
Since I can't change these callback definitions, and since I'm trying to
define the controllers purely in RBScript, I think my only option may be to
pass the callback parameters to every controller until one of them
recognises the callback reference and says "it's me!". This isn't very
efficient, and may be open to errors if two types of controllers have the
same Unique ID values.
Any other ideas? And thanks for the help!
Dave.
> From: Charles Yeomans <charles at declareSub dot com>
> Reply-To: REALbasic NUG <realbasic-nug at lists dot realsoftware dot com>
> Date: Fri, 30 Nov 2007 17:05:11 -0500
> To: REALbasic NUG <realbasic-nug at lists dot realsoftware dot com>
> Subject: Re: Some questions about delegates
>
>
> On Nov 30, 2007, at 4:54 PM, Daniel Stenning wrote:
>
>>
>>
>>
>> On 30/11/07 21:39, "Dave Addey" <listmail1 at addey dot com> wrote:
>>
>>> Hi Daniel,
>>>
>>> That does help! A few more questions in that case:
>>>
>>> 1) Where should I store "d"? Can it be a property of the class
>>> myClass?
>>>
>> You can pretty much store it anywhere you want to. But it will
>> always invoke
>> the method on the particular class instance that you created the
>> delegate
>> INSTANCE from.
>>
>>> 2) If I am registering a callback (using a declare), should I pass
>>> d as a
>>> ptr into the declare?
>> RB will convert a delegate instance into a Ptr type on the fly, so
>> I think
>> you can either declare the callback as a ptr OR the delegate name.
>> I seem to
>> recall just doing that myself recently.
>>
>>> Or something else? I guess I'm not looking to invoke
>>> the delegate myself, but rather to have it called from a callback.
>>
>> Actually - for callbacks I you cannot pass any delegate that was
>> created
>> from a class instance. Youre forced to use a global or shared
>> method. The
>> Calling conventions are different.
>
> Actually, this isn't quite right. I think it's more accurate to say
> that when a delegate is converted to Ptr, any information about the
> object is stripped, and all that's left is the function pointer
> itself. So you can pass an object method delegate to an external
> callback, but all that is passed is the function pointer, and you
> can't go back.
>
> Charles Yeomans
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|