Jump to content

Using the DLL files of an application compiled with C# with labview


Recommended Posts

#include "C:\Program Files (x86)\National Instruments\LabVIEW 2018\cintools\extcode.h"
#include "C:\Program Files (x86)\National Instruments\LabVIEW 2018\cintools\hosttype.h"
#include "HCNetSDK.h"

#define LibAPI(retval)       __declspec(dllexport) EXTERNC retval __cdecl
#define Callback(retval)     __declspec(dllexport) EXTERNC retval __stdcall

// Define LabVIEW specific datatypes to pass data as event
// This assumes that the LabVIEW event datatype is a cluster containing following elements in exactly that order!!!
// cluster
//   int32       contains the current live view handle 
//   uInt32      contains the dwDataType (NET_DVR_SYSHEAD, NET_DVR_STD_VIDEODATA, NET_DVR_STD_AUDIODATA, NET_DVR_PRIVATE_DATA,
//                                        or others as documented in the NET_DVR_SetStandardDataCallBack() function
//   array of uInt8     contains the actual byte stream data
#include "C:\Program Files (x86)\National Instruments\LabVIEW 2018\cintools\lv_prolog.h"
typedef struct
{
	int32_t size;
	uint8_t elm[1];
} LVByteArrayRec, * LVByteArrayPtr, ** LVByteArrayHdl;

typedef struct
{
	LONG realHandle;
	DWORD dataType;
	LVByteArrayHdl handle;
} LVEventData;
#include "C:\Program Files (x86)\National Instruments\LabVIEW 2018\cintools\lv_epilog.h"

Callback(void) DataCallBack(LONG lRealHandle, DWORD dwDataType, BYTE* pBuffer, DWORD dwBufSize, DWORD dwUser)
{
	LVEventData eventData = { 0 };
	MgErr err = NumericArrayResize(uB, 1, (UHandle*)&(eventData.handle), dwBufSize);
	if (!err)
	{
		LVUserEventRef userEvent = (LVUserEventRef)dwUser;
		MoveBlock(pBuffer, (*(eventData.handle))->elm, dwBufSize);
		(*(eventData.handle))->size = (int32_t)dwBufSize;
		eventData.realHandle = lRealHandle;
		eventData.dataType = dwDataType;
		PostLVUserEvent(userEvent, &eventData);
		DSDisposeHandle(eventData.handle);
	}
}

typedef BOOL(__stdcall* Type_SetStandardDataCallBack)(LONG lRealHandle, fStdDataCallBack cbStdDataCallBack, DWORD dwUser);

LibAPI(BOOL) InstallStandardCallback(LONG lRealHandle, LVUserEventRef* refnum)
{
	HANDLE hDLL = LoadLibraryW(L"HCNetSDK.dll");
	if (hDLL)
	{
		Type_SetStandardDataCallBack installFunc = (Type_SetStandardDataCallBack)GetProcAddress(hDLL, "NET_DVR_SetStandardDataCallBack");
		if (installFunc)
		{
			return installFunc(lRealHandle, DataCallBack, (DWORD)(*refnum));
		}
		FreeLibrary(hDLL);
	}
	return FALSE;
}

I am currently trying to compile.

There are 3 errors right now, I'm trying to understand the situation.

image.png.f147ab342d93a4ebff2c6fedd2039d54.png

 

Link to comment

Forgetfulness is a bad thing :) thanks for the reminder.
I fixed other issues, only the bottom one (undefined) remained and I'm trying to fix it by trying to understand what Rolfk said before.

Quote

typedef BOOL(__stdcall* Type_SetStandardDataCallBack)(LONG lRealHandle, fStdDataCallBack cbStdDataCallBack, DWORD dwUser);
 

image.png.08b5890e03a008b408f53786f9be150f.png

On 5/16/2022 at 11:49 AM, Rolf Kalbermatter said:

As to the definition for the callback pointer, I was assuming that that is somewhere in the HCNetSDK.h file but didn't check. I compiled it all without that header file. If it is not in there you simply need to copy the definition from the SDK documentation into the file just before that function.

 

Edited by alvise
Link to comment
typedef BOOL(__stdcall* Type_SetStandardDataCallBack)(LONG lRealHandle, void(CALLBACK* fStdDataCallBack), DWORD dwUser);

LibAPI(BOOL) InstallStandardCallback(LONG lRealHandle, LVUserEventRef* refnum)
{
	HMODULE hDLL = LoadLibraryW(L"HCNetSDK.dll");

This method also corrects the error.

 The error is also cleared when it is created as follows.

typedef fStdDataCallBack;
typedef BOOL(__stdcall* Type_SetStandardDataCallBack)(LONG lRealHandle,fStdDataCallBack cbStdDataCallBack, DWORD dwUser);

LibAPI(BOOL) InstallStandardCallback(LONG lRealHandle, LVUserEventRef* refnum)
{

Either way the error goes away, but I don't know which one works :)

Edited by alvise
Link to comment
On 5/28/2022 at 1:45 PM, dadreamer said:

Since BitBlt is used, your PictureBox object should be visible and on screen completely, because when it's not, then black areas are captured. PrintWindow on the other side should deal with (partially) hidden windows better, but I have no idea why it doesn't work in your case.

I do. PrintWindow sends a window message to the window function to redraw itself (WM_DRAW). The PictureBox has installed that windows function when creating the window for its drawing canvas and that function dutifully does redraw its empty PictureStream into the provided graphics context. It does not know about the bitmap that the SDK driver sneakily blitted into its window behind its back! And therefore that bitmap does not show in the PrintWindow result.

Link to comment

In the project settings you need to add:

- CINTOOLS path to Additional Include Directories field (Configuration Properties -> C/C++ -> General tab) and Additional Library Directories field (Configuration Properties -> Linker tab);

- labview.lib (or labviewv.lib) to Additional Dependencies field on the Linker -> Input tab.

Edited by dadreamer
Link to comment

Looks to me like some headers conflict... Try to #include "pch.h" as the first header file (before any other headers). Also you may remove all that C:\Program Files\... stuff from the #include directives and leave header names only, as you already specified cintools path in the project settings. If that doesn't help, disable precompiled headers to see, what happens.

Besides, those %28 and %29 characters on your screenshots look odd to me, because I had not noticed before that Visual Studio escapes some symbols in path names. Do they get added automatically?

Edited by dadreamer
Link to comment

 

10 minutes ago, dadreamer said:

Looks to me like some headers conflict... Try to #include "pch.h" as the first header file (before any other headers). Also you may remove all that C:\Program Files\... stuff from the #include directives and leave header names only, as you already specified cintools path in the project settings. If that doesn't help, disable precompiled headers to see, what happens.

that problem has been solved, this is still going on.

image.png.961c40e1047d13addfcc1f9b99455912.png

Link to comment
23 minutes ago, dadreamer said:

Looks to me like some headers conflict... Try to #include "pch.h" as the first header file (before any other headers). Also you may remove all that C:\Program Files\... stuff from the #include directives and leave header names only, as you already specified cintools path in the project settings. If that doesn't help, disable precompiled headers to see, what happens.

Besides, those %28 and %29 characters on your screenshots look odd to me, because I had not noticed before that Visual Studio escapes some symbols in path names. Do they get added automatically?

That pch.h file is for "PreCompiled Header" its an option where the compiler creates a precompiled header file for all the different headers in your project. Can be useful when you have a project that has "zillions" of source files that include "quadrillions" of header files to reduce the compilation time as the compiler doesn't have to process each header file over and over again. For a project of this size it is useless and only causes extra trouble. There should be a setting in the compiler settings called "Use Precompiled Header file" or something like that. Disable that! Then you can also remove that include.

 

 

Link to comment
32 minutes ago, dadreamer said:

Which line is this error generated at?

There is a problem with the following line. The situation we discussed earlier.

typedef BOOL(__stdcall* Type_SetStandardDataCallBack)(LONG lRealHandle, void (CALLBACK *fStdDataCallBack),DWORD dwUser);


 

 

30 minutes ago, Rolf Kalbermatter said:

That pch.h file is for "PreCompiled Header" its an option where the compiler creates a precompiled header file for all the different headers in your project. Can be useful when you have a project that has "zillions" of source files that include "quadrillions" of header files to reduce the compilation time as the compiler doesn't have to process each header file over and over again. For a project of this size it is useless and only causes extra trouble. There should be a setting in the compiler settings called "Use Precompiled Header file" or something like that. Disable that! Then you can also remove that include.

 

 

After your suggestion; Now I'm not using the pch.h precompiled header files.

Link to comment

Isn't it the same thing?

6 minutes ago, dadreamer said:

Instead of void (CALLBACK *fStdDataCallBack) try to add this:

 

The description of the error is as follows.

Quote

Severity Code Description Project File Line Suppression State
Error C2165 'left-side modifier': cannot modify pointers to data hikLabview-0.0.01

 

Edited by alvise
Link to comment

 

Then the line becomes like this, right?

typedef BOOL(__stdcall* Type_SetStandardDataCallBack)(void(CALLBACK* fStdDataCallBack) (LONG lRealHandle, DWORD dwDataType, BYTE* pBuffer, DWORD dwBufSize, DWORD dwUser));

 

If I change it like this, it starts getting the following error.

image.png.f210ed87e18bf3e93deeac8798c93cf8.png

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.