>>> If it's written in C/C++, you'd need to use the C debugger. The error does not occur on the VFP side. <<
>
>Yeah that is what I thought. I was hoping I could debug it in VFP, but I knew it was all in the DLL.
>
>OK I think I am beginning to understand what is happening in memory with the blocks now.
>
>>> One issue - 32000 is not 32K; 32K is 32768. This may be significant. <<
>
>Yes you are right. I did not read that close enough. I went and looked at the sample VB app and they did declare it as 32768. Thanks for the catch. I did check the size and the actual size being returned is 32768. So it is allocating memory blocks. I do have a pointer to the block of memory.
>
>>> Does it work in other environments? <<
>
>Yes that was my first thought as well. So I loaded VB and ran their sample app and it works in that environment. I feel like have tried everything. Everything works up to the actual DLL call.
>
>In the VB app the pointer and the sizeused parameters are LONG. Do that make a difference. What you were saying earlier was the pointer returns a INTEGER (which I checked), but the docs say pass a LONG in. I have tried all the combinations, but it still gives me the error. Declare DLL caused an exception. Any more ideas? I have no clue what to try next.
>

In VFP, the declaration of LONG and INTEGER are identical - they're both 32 bit integer values in Small-Endian format.

If you're bombing in the DECLARE, then it has nothing to do with the ClsHeap stuff.