>>>>>Is there a class out there that will convert datatypes from vfp to standard dll/(c/c++) datatypes. For instance...
>>>>>
>>>>>ulong
>>>>>pStr
>>>>>etc...
>>>>>
>>>>
>>>>What do you need to do? Simple data types declared via DECLARE DLL are converted by VFP for you; you need to know a good deal more to handle structures and pointers. You might want to look at Paul Tatavu's POINTERS class and my CLSHEAP class, which both provide mechanisms for doing some of the conversions and allocations needed to interface C-style .DLLs with VFP.
>>>
>>>Thanx for a fast reply...
>>>
>>>
>>>I need to call a function that is defined like this:
>>>
>>>ULONG PacketGetAdapterNames(PTSTR pStr, PULONG pSize)
>>>
>>>I can get it to work in Visual Basic, and even Access(scary!) but not in VFP...
>>>
>>>Both Arguments should be passed by reference.
>>>
>>>In VFP:
>>>
>>>declare PacketGetAdapterNames in c:\newpack.dll string @ long @
>>
>>DECLARE INTEGER PacketGetAdapterNames IN c:\NEWPACK.DLL ;
>> STRING @ Arg1, ;
>> INTEGER @ Arg2
>>
>>You forgot to declare the return type, and left out the comma separating the arguments in the DECLARE...DLL; the revised one should do what you want.
>>
>>>and then:
>>>mike = PacketGetAdapterNames(@buf,@namelength)
>>>and VFP returns:
>>>"Too Many Arguments."
>
>
>Ok... maybe not a pointer....
>
>But possibly a unicode string?
>or HEX and unicode? I tried STRCONV but it made it worse... I get some readable text with boxes in between the letters, I ran
>buf2 = STRCONV(buf,6)
>but I recieve even more boxes and a character that looks like a cross....
>then i run buf3 = STRCONV(buf2,2)
>same result as the prior...
>As I ran another function I recieved a string that looked like it was unicode:
>boxes in between 3 characters... but one of the characters was a (Y) with a seriff on top... Which makes me wonder if it is in HEX also...

The content of the string variable BUF should be the return from the function - if it's UniCode or ANSI double-byte characters, you'll need to do some translation using the API.

You could use CLSHEAP and handle things a bit differently:

SET PROCEDURE TO CLSHEAP ADDITIVE
oHeap = CREATEOBJ('Heap')
DECLARE INTEGER PacketGetAdapterNames IN c:\NEWPACK.DLL ;
   INTEGER Arg1, ;
   INTEGER @ Arg2 
nBufPtr = oHeap.Alloc(2000)  && allocate a static buffer of 2000 bytes
nHold = nBufPtr && in case we lose it because the .DLL call alters it
nLen = 2000
mike = PacketGetAdapterNames(@nBufPtr, @nLen)
cReturnedBuffer = GetMem(nBufPtr, nLen)
*  Use GetMem in case the .DLL does something dumb and allocates
*  its own string space;  you'll probably bleed memory if it does
*  since you'll never know when it's safe to release the memory, or
*  what memory allocation handle controls the alocation.
*
*  Ordinarily, you'd use oHeap.CopyFrom(nBufPtr) to grab the buffer
*  content, but it's tied to the buffer address of the initial
*  allocation;  GetMem() works with any linear address (but if the
*  memory doesn't exist or it doesn't belong to VFP and wasn't shared,
*  you're gonna crash!  Not a real danger here since the .DLL is in 
*  VFP's address space IAC.)
oHeap.DeAlloc(nHold)  && we don't need the original buffer any more

>
>
>
>Thanx again,
>
>
>
>Michael Mead