On using a shared DLL files in Labview

[KF]

I have been trying to call a DLL file using LabView but the problem is the particular DLL used structured parameters inside every functions. According to LabView manual, LabView could not use functions that have structures or class as arguments. Accrording to the manual, user need to write some code or CIN in order to inputs that LabView can understand. I have some doubt on this issue and I do not know how to start this with.

[Greg_McKaskle2]

> I have been trying to call a DLL file using LabView but the problem is
> the particular DLL used structured parameters inside every functions.
> According to LabView manual, LabView could not use functions that have
> structures or class as arguments. Accrording to the manual, user need
> to write some code or CIN in order to inputs that LabView can
> understand. I have some doubt on this issue and I do not know how to
> start this with.

You don't mention what version of LV you are using, but if it has the
option to set the parameter type to Adapt to Type, then for quite a few
cases, you can build a cluster in the same order as the struct and wire
that. If the struct contains pointers that LV is expected to allocate,
then this will not work, and it is q
uicker to build a small wrapper DLL
which has the parameters not in a struct, packs the struct and calls the
original.

If you post the struct definition, we can tell you whether the Adapt to
Type will work.

Greg McKaskle

[KF]

Thank you for shedding me with some light on this. For your information, I am using LabView 6i. I know that it is possible to set the type of argument to Adapt to Type but I do not know how to do so. I have gain access to the source's header file; and I always refer to this header file when I want to use the DLL. Here is the header file print:
/////////////////////////////////////////////////////

#if !defined(_FLASH_DLL_DEF_H)
#define _FLASH_DLL_DEF_H


#ifdef __cplusplus
extern "C" {
#endif


#pragma pack(push, 4)


typedef struct _FlashParameters {

//DialogBoxes Parameters
BOOL m_bUart;
BOOL m_bAddCommand;
BOOL m_bGetDebug;
BOOL m_bSkipPrimary;
BOOL m_bExeFailure;
BOOL m_bBootReplace;

BOOL m_bCRC;
BOOL m_bStartSL;
BOOL m_bQuitSL;
int m_iBootCodeAddress;


char m_cBootPath[_MAX_PATH];

BOOL m_bAutoSize;
BOOL m_bAllCom;
BOOL m_bLastConfig;
BOOL m_bEraseSectors;

BOOL m_bAdjustAU3Interval;
BOOL m_bComOption;
int m_iAU3Interval;
int m_iComOptions;


//Form Parameters
int m_iBaudRateLoader;
int m_iBaudRate;
// int m_iPort;
char m_cPort[_MAX_PATH];

char m_cOtherPath[_MAX_PATH];
char m_cLoaderPath[_MAX_PATH];
char m_cHeaderPath[_MAX_PATH];
char m_cFsPath[_MAX_PATH];
char m_cFirmwarePath[_MAX_PATH];

int m_iSoftware;
int m_iChip;

int m_iOtherCheck;
int m_iLoaderCheck;
int m_iHeaderCheck;
int m_iFsCheck;
int m_iFirmwareCheck;

int m_iFirmwareAddress;
int m_iHeaderAddress;
int m_iFsAddress;
int m_iOtherAddress;


} FlashParameters;

typedef void (DisplayFunction)(char* pszStatus);
typedef void (NotifyEndFunction)();

#pragma pack(pop)


BOOL PASCAL FLASH_DLL_START(FlashParameters *pFlashParam);

BOOL PASCAL FLASH_DLL_ABORT();
BOOL PASCAL FLASH_DLL_REGISTER_DISPLAY_FN(DisplayFunction *pDisplayFn);
BOOL PASCAL FLASH_DLL_REGISTER_DISPLAY_CHIPID_FN(DisplayFunction *pDisplayChipIDFn);
BOOL PASCAL FLASH_DLL_REGISTER_DISPLAY_PROGRESS_FN(DisplayFunction *pDisplayProgressFn);
BOOL PASCAL FLASH_DLL_REGISTER_NOTIFY_END_FN(NotifyEndFunction *pNotifyEndFn);

#ifdef __cplusplus
}
#endif

#endif

//////////////////////////////////////////////////////

The parameters that I want to gain access in all the parameters inside the structure (named FlashParameters).

[Greg_McKaskle2]

You want to build a cluster with
nine Booleans,
one Int32,
_MAX_PATH uInt8s,
six Booleans,
four int32s,
six * _MAX_PATH uInt8s,
and eleven int32s.

If you happen to know or find out that BOOL is really four bytes, then
use int32s instead of Booleans. The arrays of chars turn into a
sequence or subcluster of uInt8s. In general, you should be able to
place subClusters around elements to organize them. Finally, your
header file had a pragma statement that is a bit unknown to me. It
might mean that the parameters are four byte padded. Making a small
test program that computes sizeof(FlashParameters) and perhaps the
offset of a few fields. Offset means you need to take the address of
the field and subtract the address of the struct. This can be used to
verify the size of various fields as well as additional padding that may
be inserted by the compiler. I'm referring to this as padding, but it is
really there to align multi-byte elements to a multi-byte boundary. An
example is that some/most compilers will put four byte elements on four
byte boundaries. This means that you might need to insert additional
bytes or int16s to get match what the compiler does. I'd recommend
naming all of these with names such as pad0, pad1, etc.

Greg McKaskle


> typedef struct _FlashParameters {
>
> //DialogBoxes Parameters
> BOOL m_bUart;
> BOOL m_bAddCommand;
> BOOL m_bGetDebug;
> BOOL m_bSkipPrimary;
> BOOL m_bExeFailure;
> BOOL m_bBootReplace;
>
> BOOL m_bCRC;
> BOOL m_bStartSL;
> BOOL m_bQuitSL;
> int m_iBootCodeAddress;
>
>
> char m_cBootPath[_MAX_PATH];
>
> BOOL m_bAutoSize;
> BOOL m_bAllCom;
> BOOL m_bLastConfig;
> BOOL m_bEraseSectors;
>
> BOOL m_bAdjustAU3Interval;
> BOOL m_bComOption;
> int m_iAU3Interval;
> int m_iComOptions;
>
>
> //Form Parameters
> int m_iBaudRateLoader;
> int m_iBaudRate;
> // int m_iPort;
> char m_cPort[_MAX_PATH];
>
> char m_cOtherPath[_MAX_PATH];
> char m_cLoaderPath[_MAX_PATH];
> char m_cHeaderPath[_MAX_PATH];
> char m_cFsPath[_MAX_PATH];
> char m_cFirmwarePath[_MAX_PATH];
>
> int m_iSoftware;
> int m_iChip;
>
> int m_iOtherCheck;
> int m_iLoaderCheck;
> int m_iHeaderCheck;
> int m_iFsCheck;
> int m_iFirmwareCheck;
>
> int m_iFirmwareAddress;
> int m_iHeaderAddress;
> int m_iFsAddress;
> int m_iOtherAddress;
>
>
> } FlashParameters;