>>Can this structure be emulated in VFP 6.0?
>
>Q181289 shows you how to do this.
>
>> I have tried declaring an array of 70 elements, I also tried one long character string... until I realised that CHAR* was apointer to the value rather than the value itself. Any ideas?
>
>Think of pointers as "passing by reference". So just put an @ in front of the parameter.

A little expansion on this is needed. All values passed by reference by VFP have the actual address of a data block controlled by the NTI passed - whether the data block passed is the actual value contained in the variable passed by reference depends on how VFP stores the value internally in its memory space. Pointers embedded within structures cannot rely on addresses contained in the NTI; the data value being passed may not be the actual data block referenced in the NTI, and more importantly, the absolute location of data within VFP's address space may be altered between executable lines of code by VFP's memory manager. Pointers are absolute locations; the items they reference do not remain consistently referenced if their location in the memory space shifts - VFP is absolutely unaware that the data contains pointers, and as a result, if the data is relocated, the pointers are not adjusted to keep their referenced data in focus.

There are lots of workarounds to this - ClsHeap does this by managing static memory blocks outside of the VFP managed memory space on a private heap; as a result, the data does not get shifted when VFP rearranges its memory. Christof builds the static memory management into STRUCT; it's not as flexible at low-level pointer manipulation, and generally is not as fast as ClsHeap, but the complexities are better hidden from the developer that relies on its services.

In many cases, the data actually passed to a DLL call is not the actual data block stored in the VFP memory address space; in many cases, even when passed by reference, a copy of the variable's content is passed to the DLL. This is always the case when VFP passes a LONG, SINGLE or DOUBLE into a function which is stored in a VFP Numeric memory variable, since VFP's internal data format is not the same as the C style data representation. Also, the app can pass a literal or constant (even by reference) into a DLL call, so in order to preserve the integrity of these values, a copy is passed (or the address of the copy, as appropriate.)

Adding the @ in the DECLARE DLL statement has the effect that you note - the address of the data is passed to the DLL rather than the data value itself. However, when used in the actual DLL call, the data behaves as defined in the DECLARE DLL statement; the data block value found after the completion of the DLL call is written into the VFP memory space as an adjusted value for the variable, changed into the native VFP data representation if necessary.