> How is the DLL compiled?
Don't know. I suspect it's probably MSVC or GNU. At any rate, simple problem
easily solved, but quite difficult to explain!
-SHAWN-
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Don't know. I suspect it's probably MSVC or GNU. At any rate, simple problem
easily solved, but quite difficult to explain!
-SHAWN-
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
At least that's helpful. One easy thing to do is count up all the malloc and
free calls, or GlobalAlloc and GlobalFree, or whatever calls it's using to
do memory management... at any rate, the total should be even. More
specifically for each alloc there should be a free. If not, then it *may* be
a problem.
> Headerfile:
K. I don't see anything that is immediately indicative of a problem except
pRxStr. This is an out pointer - a pointer to a string pointer - and
actually I'm impressed you can use this.
The usual scenario with stuff like this is that the dll allocates enough
memory for the returned string and stuffs the pointer to it in the passed
address - a pointer to a string pointer. The dll assumes that the caller
frees the memory.
If that's the case, then you're right. That's where your problem is. VEE
will not free externally allocated memory. At least I'm pretty sure it
won't. It might, but that kind of attention to detail would be over and
above the call on the part of the CFI designers and to depend on it would
probably be foolish.
In fact, it will interpret this as a pointer to a string array. That it
works is somewhat surprising - if the returned string is a multiple of 16
bytes long you might run into problems with this (VEE might not see proper
termination). If you don't have to use array notation to get at the returned
string I'm amazed: somebody is performing some kind of magic and I'd love to
know what it is.
At any rate, to determine if this is a problem, check the source code for
something like this:
*pRxStr = malloc(lstrlen(pSomething));
or
*pRxStr = malloc(iRxStrLen);
The malloc may be GlobalAlloc, LocalAlloc or HeapAlloc. If you find it, then
that is definitely a problem. The solution is relatively simple though it
will take a bit of programming hassle. It can be done either with straight
VEE or a wrapper dll.
Of course the dll documentation should say exactly how to handle it. It
could be that it was designed specifically for use with VEE and it does
interpret pRxStr as a previously allocated string array, but that doesn't
seem likely. It's also possible that the function expects a pointer to a
previously allocated single buffer (as is common in the COM API with
notation such as LPVOID *ppv - see CoCreateInstance). That doesn't seem very
likely either.
-SHAWN-
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".