I have an instance of the Compaq Array Visualizer ActiveX control sitting happily on a Delphi form. I need to get data to it, and I'm using the C API provided in the aview160.dll (suitably linked to my Delphi .exe, of course).
There are constant warnings on the Delphi boards about Delphi's memory sub-allocator and DLLs. Basically, every .exe or .dll compiled with Delphi gets its own heap manager. This means that a Delphi .exe and a Delphi .dll have two seperate heap managers, which will cause corruption in one or both heaps if an allocation happens in the .exe, and the deallocation happens in the .dll. There is a Borland-supplied module (borlandmm.dll) that forces all Delphi-compiled modules to share a singleton sub-allocator, thus avoiding the problem for Delphi-to-Delphi EXEs and DLLs.
I assume that the aglAlloc(), aglMalloc(), aglMallocEx(), and aglFree() routines supplied by aview160.dll allocate memory using their own sub-allocator, perhaps supplied by the C run-time library? If so, might I assume that as long as whatever is allocated on the "Delphi side" is also deallocated there, and whatever is allocated by aglMalloc() is deallocated with aglFree(), then the actual reading and writing to the memory can happen safely on either side of the divide?
I have assumed that this is indeed the case. However, I seem to be running into problems with the aglReshape() call. The third argument to aglReshape is an integer array of dimensions, which I need to dynamically allocate on the Delphi side. Calling aglReshape() never seems to successfuly return. Is aglReshape() somehow reallocating the Delphi memory? This would corrupt the heaps, and be big trouble for me.
Sorry for the long question, and thanks in advance!