during compile CIN file 'WriteFile' error about HANDLE: works on XP not on windows7

[ledoc78]

Hello,

I have a PCI card. The supllier gave no .dll file but CIN source with VIs to control this card.

The problem is this VI doesn t work on windows 7 but works on windowsXP. On both computer Labview 2009 is installed.

I tried to compile myself the CINsource on the new computer (windows 7).

I have this message error :

error C2664: 'WriteFile' cannot convert parameter 1 from 'LVRefNum' to 'HANDLE'

the code is:

/*
* CIN source file
*/

#include <windows.h>
#include <winioctl.h>
#include <WinBase.h>
#include <extcode.h>

#define DVE120_NT_IOCTL_805 CTL_CODE(FILE_DEVICE_UNKNOWN, 0x805, METHOD_BUFFERED, FILE_ANY_ACCESS)

/*
* typedefs
*/

typedef struct {int32 dimSize;uInt8 elt[1];} TD1;
typedef TD1 **TD1Hdl;

CIN MgErr CINRun (
          LVRefNum *RefnumIn,
          TD1Hdl Array,
          uInt32 *ElementsRequested,
          uInt32 *Offset,
          uInt32 *BytesWritten,
          LVBoolean *Status );

CIN MgErr CINRun (
         LVRefNum *RefnumIn,
         TD1Hdl Array,
         uInt32 *ElementsRequested,
         uInt32 *Offset,
         uInt32 *BytesWritten,
         LVBoolean *Status )

 ....

.....

// Write out bytes.
*Status = WriteFile(*RefnumIn, // Handle to device
                             (*Array)->elt, // Buffer to driver.
                             BytesRequested, // Length of buffer in bytes.
                             BytesWritten, // Bytes placed in buffer.
                             NULL ); // LPVOID lpOverlapped (not used)

----------

Is there a difference between WriteFile function from win XP and Windows7??

Is there an other function now to send data to an hardware?

Have you an idea where come from this error?

I know that now is better to use a Library call node but for that I need to write the dll source. Is it difficult to transfom a CIN source file to a dll ?

Thank you

Roland

[dadreamer]

Maybe, you should use RefnumIn without an asterisk? Like this:

*Status = WriteFile( RefnumIn, (*Array)->elt, BytesRequested, BytesWritten, NULL );

Or cast this parameter to HANDLE (it's unsigned 32, I think?)

*Status = WriteFile( (HANDLE)(* RefnumIn), (*Array)->elt, BytesRequested, BytesWritten, NULL );

You may also try Type Cast VI in Numeric -> Data Manipulation palette before you send the parameters to CIN

[rolfk]

1) A LVRefNum is not a Windows file handle at all. Unless this refnum was explicitedly created with another call to the Windows CreateFile() API and not a LabVIEW Open File node, it will absolutely never ever work.

2) A LVRefNum is always a 32 bit variable that holds some cookie information that only LabVIEW itself knows how to interpret. A Windows HANDLE is a pointer to some memory area that only Windows knows how to interpret.

It's easily seen that a 32 bit integer can not simply be casted into a pointer on modern systems, since a pointer could be 64 bit on Windows 64 bit systems. So Micorsoft added some special declarations to the pointer sized variable declarations such as HANDLE to cause the compiler to error out when trying to convert 32 bit integers to pointers. This conversion did work in old Visual C compilers that had no support for creating 64 bit executables, since there sizeof(int32) == sizeof(void*), but this is not anymore true for compilers that can create 64 bit executables.

The solution here is to evaluate the code again. If what you are passing into the code is really a HANDLE, the code should declare this as such and not disguise it as a LVRefNum. If however you pass in a real LVRefNum (created by a File Open primitive) then you should call the LabVIEW file manager function FMWrite() instead.

3) Last but not least CINs are old legacy technology. The tools to create them have been removed from the newest LabVIEW releases and are totally unsupported on newer LabVIEW platforms such as MacOS X or Win 64 bit. They will still load in LabVIEW for Windows 32 Bit but that is about it.

Most likely the whole code could be reworked to do all the file writing in the diagram and only do the real hardware interfacing in the C code, which should be also converted to a DLL and the VIs calling it should replace the CIN nodes with according Call Library Nodes.