Pascal calling convention is obsolete in Win32. It has nothing to do
with Pascal string parameters but rather is similar to the cdecl and
stdcall calling conventions you can configure in the Call Library
Node.
Rolf K
What your problem with this is is the following assuming you declared
it as this:
static unsigned char MemoBuffer[MEMO_BUFFER_SIZE];
p4 = (int)&MemoBuffer;
hasp(MEMOHASP_READBLOCK, SeedCode, PortNum, Pass1, Pass2, &p1, &p2,
&p3, &p4)
First you assign to p4 a reference (pointer) to the pointer o
> This DLL is supplied by the hardware manufacturer and I cannot
> re-build or breakpoint the DLL as I do not have the source. I've also
> looked at the excellent "Call DLL.vi" example that ship with LV7.0 and
> have tried to replicate the Call Lib Node configuration in the VIs
> (WinCHAR.vi, ANSIu
Hello Greg
Not sure what happened in my last posting but the LabVIEW error detail
got missed off the posting!
In answer to your questions regarding the blank string buffer - I've
tried 24 bytes, 48 bytes and 100 bytes of reserved space for the
output string buffer from the DLL but LabVIEW always
> Could it be possible that LabVIEW 7.0 is not prepending the length
> correctly to the blank buffer string when using the Pascal String
> Pointer? Is there any way to check what the Pascal String Pointer
> value and contents are when it is executed in the Call Library Node
> VI?
>
> Here's the co
Hello again...
Back to looking at this problem. Have still been unable to get LabVIEW
to create a blank data buffer, pass this buffer address to the DLL and
then have the DLL return data from the hardware to this buffer
address. I have however been able to read data (two chars) at a time
from the
Hello there!
I'm trying to call a DLL supplied from hardware manufacturer and all
previous calls to the DLL have been of the form:
long hasp(long service, long seed, long lptnum, long pass1, long
pass2, long *Par1, long *Par2, long *Par3, long *Par4);
The Call Library Node is using stdcall (WI
