>>If I Replace the BYTE with STRING in VFP, if get the famous Fatal exception error C00005 !, When i use INTEGER, it works but returns wrong values.
>>
>>Yes the variable names have to be the same as the one in the DLL, it was just a typo.
>>
>>A Variable Type BYTE in VB is i Think an Integer value from 0 to 255, so why is INTEGER dont work in VFP.
>>
>An INTEGER type in VFP is 32 bits. You might try SHORT (16 bits), but you'll probably get the same results. The reason I suggested a STRING is that a normal (not Unicode) one character string contains 8 bits which is the size of a BYTE. However, VFP may include a null terminator on the string (CHR(0)) which may be causing the problems you're seeing.
>
>BTW, the only time I've see a DLL function call generate a C5 error is when the value that was passed to a function should have been declared and passed by reference, but the declaration and function passed it by value.

Then you haven't tried hard enough! < g >

It appears that VFP6 now gives a C5 error any time (1) VFP internally does something sily with a pointer, or (2) you pass something to a .DLL that'll be treated as an address that can be interpreted as an invalid memory location. Structures that contain embedded pointers are frequent culprits; strutures that are self-referential and are allocated in VFP strings are broken quite easily this way since VFP can and sometimes does move it's variables around on its own between atomic VFP operations (that's what actually got me started on CLSHEAP ages ago.) C5s seem to encompass both bounds errors (exceeding the defined top and bottom ranges allowed for memory references by a task) and my all-time favorite, the GPF, which can be caused by all sorts of improprieties with pointers and/or privileged machine instructions....