Ed,

Thanks for the explanation. I'll have to create a DLL and try some of this stuff. What you're saying is a lot different than what is described in the help for DECLARE. You think you understand something...

Jonathan

>>Sorry if I'm sounding dumb, but how is the change propagated back to VFP if you pass by value? I thought you had to pass by reference to get changes made by the called routine to be visible to the calling routine.
>>
>
>The value is reflected back to the source; eg:
>
>DECLARE SHORT Foo IN BAR.DLL INTEGER Woof
>
>* Woof is passed by value - Woof is converted to a LONG, and the value is passed
>
>? Foo(@Woof)
>
>* If the value extracted from Woof is updated, the new value is saved in Woof
>
>DECLARE SHORT Baz IN BAR.DLL INTEGER @ Woof
>
>* Woof is passed by ref - Woof is converted to a LONG, and the address of
>* the converted value is passed. The address of Woof, a VFP variable in VFP
>* internal form, is not passed
>
>? Baz(Woof) && Woof is not updated even if the buffer containing the value changes
>? Baz(@Mumble) && Mumble is updated if the function aters it
>
>Try it and see the difference. @ in the DECLARE determines if VFP passes a value or the address of the value, @ in the call determines if changes propagate back to VFP. The form of a VFP variable in memory differs from the standard internal atomic forms used by other languages; see the OnLine docs that discuss the VFP API to see how things are stored in VFP's internal formats.
>
>CLSHEAP's real mission is to give a more standard abstraction of pass by reference and pass by value, and to let the VFP programmer deal with data indirection in data structures with the same abstractions found in other languages; pass by ref and pass by value, while conceptually similar in VFP and other languages, differ in detail because of how VFP manages variables and variable references, as well as how values are represened internally by VFP for VFP data types.