Using the DLL files of an application compiled with C# with labview

[dadreamer]

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.

Edited June 1, 2022 by dadreamer

[Rolf Kalbermatter]

17 minutes ago, alvise said:

they look like below.

 

It looks right and it is certainly NOT the problem that you see no user events in the log file. If it was not good it would almost certainly crash the moment such an event was coming through.

[alvise]

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.

 

What I mean here is that currently the event structure is not reading any data.

 

2 minutes ago, dadreamer said:

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.

And that's exactly what I mean.

[alvise]

After closing and reopening the project completely I am facing a situation as below.dwdatatype returns value as 0.

[dadreamer]

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.

Edited June 1, 2022 by dadreamer

[Rolf Kalbermatter]

21 minutes ago, dadreamer said:

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.

Could it be that he simply did not activate the button again but left it pressed as it was? That state is only send on state change of the button, not because LabVIEW magically doesn't know that it should call that event case again to send the True state to the DLL.

[Rolf Kalbermatter]

18 minutes ago, alvise said:

After closing and reopening the project completely I am facing a situation as below.dwdatatype returns value as 0.

It doesn't return "anything". That indicator only gets written to in the LV User Event case. As long as you do not see such an event in the Event Inspector Window it simply means that the LVPostUserEvent() function either was not called or not with the correct user event refnum that your user event structure is registered to.

[dadreamer]

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

[alvise]

After making changes as below, nothing changed.

Preview CAM-4.vi

Edited June 1, 2022 by alvise

[dadreamer]

I opened your VI and I see this.

The array representation should be U8, not U32.

[alvise]

As a precaution against forgetting the Stream button, make a change as follows.

Preview CAM-5.vi

 

Edited June 1, 2022 by alvise

[dadreamer]

[alvise]

      a moment of distraction        

After making changes, I started to read data. Sometimes the data can be read and sometimes not.

 

Edited June 1, 2022 by alvise

[alvise]

1 hour ago, Rolf Kalbermatter said:

Could it be that he simply did not activate the button again but left it pressed as it was? That state is only send on state change of the button, not because LabVIEW magically doesn't know that it should call that event case again to send the True state to the DLL.

I guess that's exactly why sometimes it gets the data and sometimes it doesn't, I guess what you said confirms what you said after some testing.

[Rolf Kalbermatter]

56 minutes ago, dadreamer said:

I opened your VI and I see this.

The array representation should be U8, not U32.

Why did you post a picture where it was U8 and then use U32 in your Vi??????

[alvise]

At first, U32 was a numeric number, I directly converted it to an array and set the data type to U8. Later, when the problem occurred, I tried to test it with U32 numeric again.
But when I got picture as U8 I was testing as U8
Later when making changes I forgot to change it back to U8.

 

 

I think the problem still persists. Again sometimes the data is not being read.

Preview CAM-6.vi

Edited June 1, 2022 by alvise

[Rolf Kalbermatter]

37 minutes ago, alvise said:

At first, U32 was a numeric number, I directly converted it to an array and set the data type to U8. Later, when the problem occurred, I tried to test it with U32 numeric again.
But when I got picture as U8 I was testing as U8
Later when making changes I forgot to change it back to U8.

This type of error is very quickly the difference between a crashing monster and a well behaving application. There is no LabVIEW who can save you from this. It is YOU who has to make sure that what you write in the external code, matches exactly what you tell LabVIEW to expect. It must be able to trust you blindly on this or your library is nothing more than a bunch of crashing dummies. If you can't make sure of that because you obviously don't understand the actual implications and/or easily forget about them after they have been explained to you a few posts earlier, then you are truly playing with fire in trying to create such a library. Seriously!

Quote

I think the problem still persists. Again sometimes the data is not being read.

That are the statements I love in every problem description. Very precise and to the point, NOT!

How does it look when you conclude it is not read? Does just the array get empty data? Do the other values such as lRealHandle turn to show a different value too? And which one?

Right now it is like I show you a picture of a nice car (your image shows that there is actually data) and then tell you he doesn't sometimes work. Can you help me? Who could except someone with clairvoyant abilities?

Does it start? Does it suddenly stop? Are you sure there is gas in the tank? Do any lights in the dashboard light up?  You see what I'm saying?

Edited June 1, 2022 by Rolf Kalbermatter

[alvise]

5 minutes ago, Rolf Kalbermatter said:

This type of error is very quickly the difference between a crashing monster and a well behaving application. There is no LabVIEW who can save you from this. It is YOU who has to make sure that what you write in the external code, matches exactly what you tell LabVIEW to expect. It must be able to trust you blindly on this or your library is nothing more than a bunch of crashing dummies. If you can't make sure of that because you obviously don't understand the actual implications and/or easily forget about them after they have been explained to you a few posts earlier, then you are truly playing with fire in trying to create such a library. Seriously!

 

I try to be very careful. But sometimes accidents like this happen.Thanks for your warning.

7 minutes ago, Rolf Kalbermatter said:

That are the statements I love in every problem description. Very precise and to the point, NOT!

How does it look when you conclude it is not read? Does just the array get empty data? Do the other values such as lRealHandle turn to show a different value too? And which one?

Right now it is like I show you a picture of a nice car (your image shows that there is actually data) and then tell you he doesn't sometimes work. Can you help me? Who could except someone with clairvoyant abilities?

Does it start? Does it suddenly stop? Are you sure there is gas in the tank? Do any lights in the dashboard light up?  You see what I'm saying?

-For example, if I run VI (if I press each key properly), the data (numbers) in the array are constantly changing, and on this basis, I say that the data can be read.
But sometimes (perhaps after running and stopping VI a few times) the string contains data from the previous run and the data (number) remains constant in the array. I interpret this situation as no data read.

I don't know how self-explanatory it was. Referring to the car example also reminded me how dire my situation was.

-I've been reading over and over when you wrote how to create -installcallback.vi. But I didn't understand exactly what to do.

 

[dadreamer]

You still did not apply UninstallCallback to your VI. This may help or may not. I can't say now, what's the reason behind your problem. When you will be ready to test with UninstallCallback, restart LabVIEW completely to begin with fresh resources.

And as you already are getting stream's binary data, save a single NET_DVR_SYSHEAD (1) packet and a single NET_DVR_STREAMDATA (2) packet to two separate binary files, so we could get a chance to look at the format. Use a Case Structure to differentiate them. Save one packet only, if possible, not two going one after the other. Post them afterwards.

Edited June 1, 2022 by dadreamer

[alvise]

From what I understand so far, uninstallcalback should be created in dll and use in labview with Not A refnum (no reference) to delete callback if stop button is pressed.
The dll file should understand this no-reference status and run the remove function and remove the callback.It should release the library for that.

I need to create 2 parameters in this function.1-Return 2- for ''Not A Refnum'' connection.

I'm experimenting by doing research and commenting out the existing code.
But I haven't been able to find exactly how the code needs to be able to perform the callback function.

I came to the following conclusion.I guess it should be created as follows, right?

typedef BOOL(__stdcall* Type_SetStandardDataCallBack)(LONG lRealHandle, void(CALLBACK* fStdDataCallBack) (LONG lRealHandle, DWORD dwDataType, BYTE* pBuffer, DWORD dwBufSize, DWORD dwUser), DWORD dwUser);
extern "C" __declspec(dllexport) BOOL __cdecl unInstallStandardCallback(LONG lRealHandle, LVUserEventRef * refnum)
{
    HMODULE hDLL = LoadLibraryW(L"HCNetSDK.dll");
    if (hDLL)
    {
        Type_SetStandardDataCallBack uninstallFunc = (Type_SetStandardDataCallBack)GetProcAddress(hDLL, "NET_DVR_SetStandardDataCallBack");
        if (uninstallFunc)
        {
            FreeLibrary(hDLL);
         
        }
        
    }

}

I don't know if I have established a correct logic

Either I'm really walking towards a light or at the end of the road I will realize that that light is the light that the firefly emits to catch its prey, of course, it is too late for everything now 

Edited June 1, 2022 by alvise

[Rolf Kalbermatter]

18 minutes ago, alvise said:

From what I understand so far, uninstallcalback should be created in dll and use in labview with Not A refnum (no reference) to delete callback if stop button is pressed.
The dll file should understand this no-reference status and run the remove function and remove the callback.It should release the library for that.

I need to create 2 parameters in this function.1-Return 2- for ''Not A Refnum'' connection.

I'm experimenting by doing research and commenting out the existing code.
But I haven't been able to find exactly how the code needs to be able to perform the callback function.

I came to the following conclusion.I guess it should be created as follows, right?

typedef BOOL(__stdcall* Type_SetStandardDataCallBack)(LONG lRealHandle, void(CALLBACK* fStdDataCallBack) (LONG lRealHandle, DWORD dwDataType, BYTE* pBuffer, DWORD dwBufSize, DWORD dwUser), DWORD dwUser);
extern "C" __declspec(dllexport) BOOL __cdecl unInstallStandardCallback(LONG lRealHandle, LVUserEventRef * refnum)
{
    HMODULE hDLL = LoadLibraryW(L"HCNetSDK.dll");
    if (hDLL)
    {
        Type_SetStandardDataCallBack uninstallFunc = (Type_SetStandardDataCallBack)GetProcAddress(hDLL, "NET_DVR_SetStandardDataCallBack");
        if (uninstallFunc)
        {
            FreeLibrary(hDLL);
         
        }
        
    }

}

I don't know if I have established a correct logic

Either I'm really walking towards a light or at the end of the road I will realize that that light is the light that the firefly emits to catch its prey, of course, it is too late for everything now 

Go back to this post and look at the code and the explanation I gave there!

If you want to stay with analogies, it could be also the headlights of the train that is running to roll over you. 😆

Edited June 1, 2022 by Rolf Kalbermatter

[alvise]

I don't experiment too much as I don't want to make mistakes. I want to run sensible tests.
I read your previous post maybe 10-20 times.
I think I need to pass a "Not a Refnum" to the installcalback function you describe here and create it in the stop event frame.

Of course I tried that, no difference.

Edited June 2, 2022 by alvise

[dadreamer]

1 hour ago, alvise said:

Of course I tried that, no difference.

These modifications were made as well?

extern "C" __declspec(dllexport) BOOL __cdecl InstallStandardCallback(LONG lRealHandle, LVUserEventRef * refnum)
{
    HMODULE hDLL = LoadLibraryW(L"HCNetSDK.dll");
    if (hDLL)
    {
        Type_SetStandardDataCallBack installFunc = (Type_SetStandardDataCallBack)GetProcAddress(hDLL, "NET_DVR_SetStandardDataCallBack");
        if (installFunc)
        {
            if (refnum && *refnum) 
                return installFunc(lRealHandle, DataCallBack, (DWORD)(*refnum));
            else
                return installFunc(lRealHandle, NULL, 0));
        }
        FreeLibrary(hDLL);
    }
    return FALSE;
}

 

[alvise]

No, no changes have been made here.

extern "C" __declspec(dllexport) BOOL __cdecl InstallStandardCallback(LONG lRealHandle, LVUserEventRef * refnum)
{
    HMODULE hDLL = LoadLibraryW(L"HCNetSDK.dll");
    if (hDLL)
    {
        Type_SetStandardDataCallBack installFunc = (Type_SetStandardDataCallBack)GetProcAddress(hDLL, "NET_DVR_SetStandardDataCallBack");
        if (installFunc)
        {
            if (refnum && *refnum) 
                return installFunc(lRealHandle, DataCallBack, (DWORD)(*refnum));
            else
                return installFunc(lRealHandle, NULL, 0));
        }
        FreeLibrary(hDLL);
    }
    return FALSE;
}

 

Edited June 2, 2022 by alvise

[dadreamer]

23 minutes ago, alvise said:

No, no changes have been made here.

Why not? 🥴