dadreamer

I see two main issues here.

1. Too many events coming - your program just can't handle them all at once (you were already warned about that). How can you deal with it? You decide. I often use a boolean variable switch for that. You may consider something else.
2. You want to have UninstallStandardCallback function to stop posting into LV, when the loop finishes or no matter what. Now your DLL seems to be trying to post even when the main VI finishes plus the event queue is full with unprocessed events. Try to implement that function on your own, it's not that complex.

10 minutes ago, alvise said:

What is the reason why the Handle value is sometimes flickering on the screen?

Maybe because on each event a new handle is allocated?

Now you're gonna have some fun with MoveBlock thingy 😉 Does your loop manage to process events in time?

Don't pass Event Registration Refnum to the DLL! Pass Event Refnum.

Also you need to pass this wire through all the frames of the structure, because when the loop will be stopped, Destroy User Event VI will be confused getting invalid refnum. Or wire it around the loop instead. Oh, first do unregister, second do destroy, in that order.

Moreover your calling convention is wrong!

Plus you didn't insert an User Event frame where you're going to catch your events.

! Reg Events, Unregister and Destroy should be either outside the loop completely or inside the "Start" (for Reg Events) and "Stop" (for Unregister and Destroy) frames ! Otherwise the UE will be created and freed on each iteration.

You better rework Rolf's example a bit to not reinvent the wheel.

1. Remove this as no longer needed.

2. Remove this Case Structure and that VI Ref terminal. Pass NULL (0) as hPlayWnd.

3. Before the While loop create User Event of cluster type, containing these three fields:

typedef struct
{
	LONG realHandle;
	DWORD dataType;
	LVByteArrayHdl handle;
} LVEventData;

You should set handle type as U32, if you're working in 32-bit LabVIEW only, or U64 in all other cases.

4. In "Start" frame of the Event Structure right after Start.vi put CLFN with InstallStandardCallback function call, set it properly and pass two parameters to it - lSession from Start.vi and your fresh UE reference.

5. Activate Dynamic Events terminals on your Event Structure and set it to accept your User Event. Also here register for events and pass the event refnum to the right terminal.

6. In "Stop" frame of the Event Structure unregister for events.

7. After the loop destroy the UE.

Now after running your program and pressing "Connect" + "Start" buttons you should receive some events (if no mistakes made). Check Event Inspector window to make sure.

You may trash down Release folder and rebuild the project in Release config. Or leave it as is. But when you will distribute your app onto another machines without Visual Studio installed, your library will ask for the debug version of MSVC Runtime.

10 minutes ago, alvise said:

There is no problem here, is there?

There is! Alter the function declarations and add these prototypes.

extern "C" __declspec(dllexport) void __stdcall DataCallBack(LONG lRealHandle, DWORD dwDataType, BYTE *pBuffer, DWORD dwBufSize, DWORD dwUser);

extern "C" __declspec(dllexport) BOOL __cdecl InstallStandardCallback(LONG lRealHandle, LVUserEventRef *refnum);

I don't see the functions prototypes declared anywhere in the source. Maybe this is the reason. Try to add them right after the last #include directive.

Callback(void) DataCallBack(LONG lRealHandle, DWORD dwDataType, BYTE *pBuffer, DWORD dwBufSize, DWORD dwUser);

And

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

11 minutes ago, alvise said:

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

Yes. Your code does already have all that necessary stuff for export:

#define LibAPI(retval)       __declspec(dllexport) EXTERNC retval __cdecl
#define Callback(retval)     __declspec(dllexport) EXTERNC retval __stdcall
// ...
Callback(void) DataCallBack(LONG lRealHandle, DWORD dwDataType, BYTE *pBuffer, DWORD dwBufSize, DWORD dwUser)
{
// ...
}

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

Hence it's rather odd that nothing is exported. As you're using __declspec(dllexport), no need to use .def file - you may disable it in the settings.

Maybe your functions are exported, but have decorated names... In this case LabVIEW won't show them. Could you check full export table with some tool like Dependency Walker or similar?

These four functions should be there, they are "service" functions for LabVIEW core. But your functions did not get exported at all for some reason.

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?

There are literally zero chances that someone would hack you through callback DLL, that will be loaded into LabVIEW address space. 😃

https://stackoverflow.com/questions/10599940/module-unsafe-for-safeseh-image-c

Quote

Is it okay if safesh is disabled?

For this project - yes.

Quote

This linker option is intended to protect exception handler records on the stack from being overwritten.

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

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.

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)

Which line is this error generated at?

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?

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.

Just switch it to Release.

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.

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

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

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

18 minutes ago, alvise said:

You mentioned earlier a method that can be done without using callback. What method is this?

Callback is still needed. I said that PostLVUserEvent call may be omitted.

On 5/27/2022 at 5:00 PM, dadreamer said:

There exists an easier callback variation, that doesn't involve calling PostLVUserEvent.

If you don't know C even at very basic level and can't compile DLLs, I'm afraid I can't help here. There are many example on making C/C++ DLLs on the net. My advice is to learn them carefully and only after that go to callback things.

27 minutes ago, alvise said:

It must always have two images on the screen and the Picturebox must always be in the middle of the screen, right?

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.