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

[ShaunR]

5 hours ago, alvise said:

I know c/c++ at a basic level. I can compile it if there is a sample code. I just don't know how to create a piece of code for this callback function.

 

You were already given it, no?

 

[dadreamer]

@alvise

Yeah, just try to compile Rolf's code, it's already done and intended for your case exactly. Wait no more.

Edited May 28, 2022 by dadreamer

[alvise]

#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.

 

[dadreamer]

1 hour ago, alvise said:

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

You've dealt with them before.

 

[alvise]

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);
 

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 May 28, 2022 by alvise

[dadreamer]

I assume, fStdDataCallBack cbStdDataCallBack might be replaced with void(CALLBACK *fStdDataCallBack) (LONG lRealHandle, DWORD dwDataType, BYTE *pBuffer,DWORD dwBufSize,DWORD dwUser)

Edited May 28, 2022 by dadreamer

[alvise]

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 May 28, 2022 by alvise

[dadreamer]

So you got that DLL compiled? Also to note, switch to Release configuration as you very likely are not going to debug that DLL by the MSVC debugger. Doing that you should have proper linking to the MSVC Runtime instead of the debug libraries.

[alvise]

No, I haven't compiled it yet, but I don't fully understand what you're saying.
I opened the project directly with the Dynamic library. I think everything in the picture below is correct.

[dadreamer]

Just switch it to Release.

[Rolf Kalbermatter]

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.

[alvise]

There is a file named pch.h, when I add it, I get a problem like the following. If I don't add it, it says you forgot the file named pch.h and gives an error

[dadreamer]

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 May 29, 2022 by dadreamer

[alvise]

 

I set it as above, but I still keep getting the following errors.

 

[dadreamer]

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 May 29, 2022 by dadreamer

[alvise]

 

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.

[dadreamer]

Which line is this error generated at?

[Rolf Kalbermatter]

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.

 

 

[alvise]

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.

[dadreamer]

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

21 hours ago, dadreamer said:

void(CALLBACK *fStdDataCallBack) (LONG lRealHandle, DWORD dwDataType, BYTE *pBuffer,DWORD dwBufSize,DWORD dwUser)

 

[alvise]

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 May 29, 2022 by alvise

[dadreamer]

In your code the callback function doesn't have parameters. Likely this is not reason for the error you shown, but it's better to specify the parameters explicitly.

[alvise]

 

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.

[dadreamer]

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

 

[alvise]

 

Started getting this error.

Is it okay if safesh is disabled?

Edited May 29, 2022 by alvise