On 28-Apr-07, at 3:47 PM, Thomas Cunningham wrote:

> Looking for some more help with callbacks. A few questions if I  
> might. This
> is from Apple Docs.
>
>   Defines a CGFunction evaluator callback type.
>
>   typedef void (*CGFunctionEvaluateCallback) (
>   void *info,
>   const float *inData,
>   float *outData
>   );
>
>   If you name your function MyCGFunctionEvaluate, you would declare  
> it like
> this:
>
>   void MyCGFunctionEvaluate (
>   void *info,
>   const float *inData,
>   float *outData
>   );
>
> 1) I want to confirm that my Rb Routine parameters are correct? I  
> have this,
>
> RedBlackRedRampEvaluate(ByRef info As MemoryBlock, inValue As  
> MemoryBlock,
> ByRef outValue As MemoryBlock)

This should just be Ptr. Byref is not required.
RedBlackRedRampEvaluate( info As Ptr, inValue As Ptr, outValue As Ptr)

> I've also tried defining these parameters as Ptr with ByRef and  
> without.
> However, when I pass the AddressOf RedBlackRedRampEvaluate to a  
> declare I am
> using, the items in this routine are not doing anything to, in this  
> case,
> change colors properly. At least  I think this is where it is failing.
>
> 2) What is the sequence of calls and events when you pass an  
> AddressOf call?
> It looks like the routine and its associated code is executed, right?

Not sure what exactly you mean.
Whatever you give the AddressOf TO will call your routine with  
parameters at some point.

> 3) Since we don't pass the parameters required for this evaluator  
> function
> via our call to AddressOf, how does it find these properties? i.e.  
> info,
> inData, outData.

The caller puts them on the stack (usually) according to that  
lannguages calling conventions (which appear to be C)
They should be set already when you are called assuming there's  
nothing funky about calling conventions.
It should be OK as is for what you are trying to do.

> 4) Unrelated to callbacks, but ... In this line of code,
>
> const float *inData
>
> The constant keyword indicates that once it is set it can not be  
> changed.

It means the PTR cannot be changed but the thing the Ptr is pointing  
at can be

> The * indicates Dereference(indirect value). How can I duplicate  
> these "rules" or do I need to care?

Just don't try and change the Ptr.
You can alter the data the pointer points to though.

Conceptually what you cannot do is

        outValue = new MemoryBlock // can't do this as it would try to  
change what outValue points at

but you could do (again, conceptually)

        outValue.long(0) = &hff00cc

or something similar (assuming any of this were syntactically valid)


_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Reply via email to