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?

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.

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

Now correct the cluster contents as proposed and test again.

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.

Because you exported it. Leave it as is. 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.

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:

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

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.

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

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