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?

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? The description of the error is as follows.

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); After your suggestion; Now I'm not using the pch.h precompiled header files.

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.

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

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.

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