Difficulties calling kernel 32.dll from Call Library Function Node

[Scott Stewart]

I have had a nagging problem with calling kernel32.dll using the Call Library Function Node function. I have consistently had the same problem with LabView 7 & 8; using both windows NT, 2K and XP. I have to hack at connecting/disconnecting and configuring the Call Library Function Node sometimes for a day before it starts working, and I would like to understand the problem better. Invariably after a day of rewriting the portion of the VI with the CLFN function, it starts working for no apparent reason. Until it starts working, I usually get a '259' value in one of the return values. Once it starts working on a single computer, it continues to work. If I copy the working VI to a different computer, I have to start the hacking all over again until it starts working. My best guess is that there must be a problem with the resolution of a pointer, but I am desperate for any help the LV community may have out there. Sound familiar to anyone out the in LabView land? Any help would be greatly appreciated.....Thanks.

[tbd]

Hi Scott,

      What kernel32 function are you calling, and, can you attach the VI which calls the CLF?

Cheers.

[Scott Stewart]

TBD-

I have had problems calling DeviceIOControl, CreateFileA, Writefile and others. I am attaching a sample of a vi calling WriteFile.

Thanks,

Scott

[tbd]

Hi Scott,

Thanks for the VI - unfortunately I couldn't open it! (LV7.1 here)

You migh back-save it for us cavemen, but first...

I did research WriteFile and put-together this VI in case it points-up any obvious differences from yours (which I doubt.)

A couple of suspected gotcha's are to make sure hFile is not defined as a pointer to value.  Use an array of bytes for the buffer (the prototype treats them as a char-array anyway.)  Make sure the NumberOfBytesToWrite isn't bigger than the Array-in, the effect of null-writes are file-system dependent - better to avoid it altogether.  Make sure NumberOfBytesWritten is pointer to a value (DWORD), and wire the input-side.  I hope we're not doing OverLapped writes!

[Scott Stewart]

TBD -

  Thanks for the input. No I do not use overlapped IO. My call looks the same except...

isn't the OVERLAPPED argument a LP (long pointer) ?

Scott

[tbd]

Hi Scott,

> isn't the OVERLAPPED argument a LP (long pointer) ?

NO! (well yes, but..) If you specify this parameter as a pointer in the CLF, LabVIEW will pass a non-null pointer value (pointing to a U32), but the DLL will expect to find an Over-lap info-structure where it points.

The way to pass a null-pointer to the DLL is to pass a U32 - by value - set to zero.  The DLL, expecting a pointer, will interpret the U32 (set to zero) as a null-pointer - which is what you want.

This will be true anywhere a Null-pointer needs to be passed.

Hope it helps!