On Apr 30, 2007, at 12:55 AM, Thomas Cunningham wrote:
> Christian, this is a plugin free project for me. :-)
>
> Norman Wrote:
>>> 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)
>
> Charles Wrote:
>> Probably you should declare all three parameters to be of type
>> MemoryBlock.
>
>> Sub RedBlackRedRampEvaluate(info as MemoryBlock, inValue as
>> MemoryBlock, outValue as MemoryBlock)
>
> These two replies indicate my fundamental question. It appears that
> there is
> no *correct* answer, other than to try each out and see what
> works. :-)
Here, either declaration should work. This is just a US v. Canadian
thing.
>
> Norman Wrote:
>> 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.
>
> I'm still confused. Let's say you have a Routine and a call,
> // Method
> MyTestRoutine(aPtr As MemoryBlock)
> // a Call
> Dim temp As New MemoryBlock(12)
> temp.Ptr(4) = AddressOf MyTestRoutine
>
> How does Rb find the parameter aPtr in MyTestRoutine? By name?
Rb doesn't find it; CoreGraphics does. It calls the function
MyTestRoutine (via the function pointer) and so it must know the
parameters it wants to pass.
>
>> It means the PTR cannot be changed but the thing the Ptr is pointing
>> at can be. Just don't try and change the Ptr. You can alter the
>> data the
> pointer points to though.
>
> Ah, that's it. thank you.
>
> Charles Wrote:
>> In this case, you need to examine the documentation for
>> CGFunctionEvaluateCallback. The second and third parameters are
>> arrays of type float whose sizes you supplied to CGFunctionCreate.
>> Probably you should declare all three parameters to be of type
>> MemoryBlock.
>
> I try to only post here without many many times reading the docs,
> as is the
> case here. The docs at this point are not getting me what I am
> looking to
> do, yet.
Sorry; I didn't mean to suggest that you did not look at the
documentation. In this case, the function prototype just did not
tell the entire story.
>
>> You might want to post your code for CGFunctionCreate; that has to be
>> done correctly for the callbacks to work.
>
> Right, I understand the connection to this. I have at this point,
>
> // info ptr variable
> infoPtr.UInt32(0) = CGColorSpaceGetNumberOfComponents(aClrSpace)
> + 1 // 4
>
> // Dimension of aDomain is 1 and dimension of aRange is 4.
> aFunctionRef = CGFunctionCreate(infoPtr, 1, aDomain, 4, aRange,
> aCallBack)
>
> aDomain and aRange are MemoryBlock with floats (singles) that
> correspond
> (sized and assigned) to 1 and 4 parameters at 4 bytes each.
In your code, I'd suggest replacing 1 and 4 with aDomain.Size\4 and
aRange.Size\4 .
> aCallback is a
> MemoryBlock class with its evaluate pointer set to,
>
> aCallBack.Ptr(4) = AddressOf MyRedBlackRedRampEvaluate
>
> The Callback structure is,
>
> struct CGFunctionCallbacks
> {
> unsigned int version;
> CGFunctionEvaluateCallback evaluate;
> CGFunctionReleaseInfoCallback releaseInfo
> };
>
Finally, the MemoryBlock infoPtr needs to live for as long as it's
needed -- are you keeping a reference to it in a property somewhere?
Charles Yeomans
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
