alvise

I checked and it looks like below.

To export functions like here, it is necessary to make changes in the code, right?

I also made the following settings for export, but still the same

Is it normal for the dll file's functions to look like this?

17 minutes ago, dadreamer said:

All you need is to disable option "Image has Safe Exception Handlers" in Project properties -> Configuration Properties -> Linker -> Advanced tab. Why are you trying to adjust Debug config, when you're on Release one?

After selecting it as a release again, I built it.
I just missed it. I fixed it.

ok. now .dll file has been created.

I needed to make sure the code wouldn't hijack my computer
I guess I need to implement them.

step 1:

step 2:Do you need to choose stdcall?

Is it safe to disable it?

Started getting this error.

Is it okay if safesh is disabled?

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.

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

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.

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.

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

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

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.

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

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.

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

In fact, I'm clearly convinced that I should work with the Callback function. When I try to draw directly on the picturebox picture the video starts fighting with the picture drawn on the screen and I get a very bad flicker. This causes a lot of hassle when trying to use it with image processing.
So in this case there is nothing left to do, I will have to create a wrapper dll.

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.

Having two images and especially the Picturebox screen that is constantly on the screen takes up a lot of space and I can't always fit it on the screen. You mentioned earlier a method that can be done without using callback. What method is this? and also I don't know how to create a C++ example code with callback function as I don't really understand the callback thing.

19 minutes ago, dadreamer said:

 pass further to the VI.           

I don't quite understand what you mean to say here.

-BitBlt button is already pressed, if I don't press it, it can't take any image.
I changed it to -ToInt64, it's ok.

It works, but there is a small problem
It must always have two images on the screen and the Picturebox must always be in the middle of the screen, right?

I guess that's the method dadreamer said.

I tried this and got a result like the one below. It can take a screenshot, but it has a disadvantage, of course, it reads the whole of the main screen and reads it according to the movement of the slider bar 

The disadvantages are the same in both cases because if I pull the scroll bars down, the image changes.The good thing about this method is that it only takes the picturebox screen. But Moving the scrollbar of the Fronpanel turns the picturebox a black color around it.

9 hours ago, Neil Pate said:

I have nothing to add to this thread, other than @alvise I think if you get this working you owe a few people some beer 🙂

To those patiently contributing to this thread, I sincerely thank you. This community is so much stronger due to you folks. Please never leave!

My debt is debt  The problem here is weird and interesting.

Gribo I agree with what rolfk said here. I tried something like this and got no results.

6 hours ago, Rolf Kalbermatter said:

That callback will almost certainly never get triggered! The SDK is not aware about that it is drawing into a .Net PictureBox. It only sees the window handle that is used by the PictureBox for its drawing canvas. And that works on a level way below .Net in the Windows window manager inside the kernel. If you would try to do anything with that PictureBox such as drawing lines or anything into, it you would get very nasty flickering as the SDK function trying to bitblit into the windows device context (HDC) will fight with the PictureBox functions who tries to do GDI drawing into the same HDC. We are abusing here the PictureBox simply as a container to provide a window handle. In this way we can let Windows window clipping handle all the issues about making sure that the SDK can't draw beyond that area provided by the PictureBox control. But for the rest we are not really using any functionality from the PictureBox .Net control. Respectively when we tried to retrieve the image, that failed since the PictureBox control is not aware about what was drawn into its window. And the same applies for the LabVIEW Get Image control function.

I tried to capture the image for the whole Main VI screen, everything is showing but the video in the picturebox area is not showing, interesting thing.

6 hours ago, Rolf Kalbermatter said:

It wasn't me who brought that back into the discussion. I was under the strong impression that we were already working for some time on the PictureBox solution as drawing canvas area. alvise suddenly brought this Empty.vi subpanel solution back into the picture.

I was wondering how it would be with the VI screen, but of course the result is disappointment

No I haven't tried it, how exactly should I do it?