dadreamer

I opened your VI and I see this.

The array representation should be U8, not U32.

@alvise I also recommend putting a CLFN with SetCbState call and wire a False constant to it after the While loop, so it would deny posting anyways.

Could it be that the callback doesn't get installed? Did you try to uninstall it after the loop ends?

21 hours ago, Rolf Kalbermatter said:

Then write an Uninstall Callback.vi that is essentially the same as the Install Callback.vi but don't pass in any user event refnum. Simply pass a NotARefnum to the second parameter of the Call Library Node.

5 minutes ago, Rolf Kalbermatter said:

I have absolutely no idea what you mean when you say that no RealHandle data is visible. As far as that log looks, no event is ever sent. This could be happening if your cbState boolean was never set to true.

If I got it right, he says that on one run of the VI the events are being sent OK, but on another run (after he stops the VI and runs it again) no events is sent regardless of the button being pressed.

Is your cluster elements order correct? Open Context Help window, then select Wiring Tool and hover it over the pink wire. In the Context Help you'll see order of the cluster elements.

@alvise

Do you really need audio in your streams? Because if no, then it would be a way easier to work with pure NET_DVR_STD_VIDEODATA (4) packets.

3 minutes ago, alvise said:

are you talking about this?

Yes. Make handle as U8 array instead of a numeric.

6 minutes ago, alvise said:

Is it normal to get an output like the one below? Because sometimes I get Realhandle data. Sometimes I don't.

Now correct the cluster contents as proposed and test again.

16 minutes ago, Rolf Kalbermatter said:

And ohhhhhhhhhhhh my God!!!!!! You defined the event data cluster totally wrong. That "handle" is not an integer value. It is a full and complete LabVIEW byte array!! It shouldn't cause your crash .. at least not immediately! But since you don't tell LabVIEW that it is a handle it can't manage its memory. Meaning with every message that is sent to your event loop, you simply leak that handle each time. That will drive your application into out of memory in no time, just as the incorrect handling of the cbState boolean did. You not only were leaking handles when the cbState boolean was false but with EVERY single callback!!!!!!!!

This explains why he was seeing unstable behaviour from run to run. This is what happens, when two advisers are trying to help simultaneously. 😃 I often prefer a slightly different way to transfer data from the callback. I post a pointer to data and in LabVIEW I read it out with MoveBlock (because I like to see a minimalistic external code and do most of the coding in LV instead).

By the way, I kind of think posting an U32/U64 number might work, if DSDisposeHandle would be moved to the LV Event frame from the callback code and in that frame MoveBlock + DSDisposeHandle would be called.

10 minutes ago, alvise said:

Why was the "Datacallback" function in the picture above created, is it necessary to get information using that function?

Because you exported it. Leave it as is.

11 minutes ago, alvise said:

Now I'm trying to figure out how can I send the true-falsa flag.

Take a boolean button with Switch when released mechanical action and create a new event frame "Value Change" with that button inside. Put a CLFN with SetCbState call, add one parameter in its settings with Adapt to Type -> Handles by Values data type and format. Wire your button to the CLFN. Now you're controlling the callback event flow.

1 hour ago, alvise said:

Do you think I should create it as follows?

Rolf nailed it already 🙂 So do as written above.

Why did you leave eventData declaration and NumericArrayResize call outside the condition? Unnecessary work for the callback to do, if the flag is False.

There's also a mistake in your code. Compare with this:

1 hour ago, alvise said:

-Boolean variable switch must be created inside the  dll file and it is necessary to send a value (1-0) to it from the labview, right?

Yes, something like this:

extern "C" __declspec(dllexport) void __cdecl SetCbState(LVBoolean *state);
// ...
LVBoolean cbState = LVBooleanFalse;
// ...
extern "C" __declspec(dllexport) void __cdecl SetCbState(LVBoolean *state)
{
  cbState = *state;
}
// ...
extern "C" __declspec(dllexport) void __stdcall DataCallBack(LONG lRealHandle, DWORD dwDataType, BYTE *pBuffer, DWORD dwBufSize, DWORD dwUser)
{
  if (cbState==LVBooleanTrue){
    // callback code
  }
}

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