dadreamer

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.

Glad something finally worked for you 🙂 What about pressing that BitBlt button? And you don't need to cast the handle to U64 - just change ToInt32 method to ToInt64 and pass the wires to the VI.

There exists an easier callback variation, that doesn't involve calling PostLVUserEvent. I have used it few times in the projects with VLC video streaming from several cameras. It's an asynchronous method too, but it works for sure. The main point is that on the diagram we call DSNewPtr and pass new pointer to the library. When the callback is called, it just writes data by that pointer. In LabVIEW we just read the data by the pointer constantly and process it, if necessary. It's good for common video translation or for simple image processing, when not each video frame is required. Still needs the DLL to be written/compiled though.

3 hours ago, Rolf Kalbermatter said:

Doesn't matter. The SDK draws asynchonously into the Picture Box window. No matter which window handle you use, the moment you cause the screen capture from the window handle to occur is totally and completely asynchronous to the drawing of the SDK. And there is a high chance that the screen capture operations BitBlit() or PrintWindow() will capture parts of two different images drawn (blitted into the window) by the SDK function.

I meant this part:

It just makes no sense to capture Empty.vi window and a little sense to capture the whole main VI window, when a concrete .NET window region is wanted. Ok, when drawn onto Empty.vi panel, the whole window must be captured.

I assumed, you would feed the PictureBox handle into Get Image By HWND.vi instead of feeding a panel window handle. No need to use FP.NativeWindow here. Just typecast the handle refnum to U64 and wire to that VI.

15 minutes ago, alvise said:

I tested this example you shared, if I use it with a VI with no display screen it's fine, everything works fine but when I try to use it with live video streaming it causes the display to be choppy and not capture the whole screen.

Share your VI or a snippet.

I'm not a big fan of Get Image method, because it has a whole load of disadvantages:

• runs in UI thread only;
• requires a front panel to be open (and visible to reflect the changes);
• redraws an image after the control modified it (i.e., scaling, cropping etc.), so if you have the original image of 1024*1280 pixels and it's rendered into the control of 10x10 pixels, you'll get those 10x10 pixels instead;
• draws control's label/caption additionally (sometimes it's wanted, sometimes not);
• doesn't work for some third party ActiveX/.NET controls (maybe, because they all use different rendering techniques);
• sometimes lags / doesn't capture the image.

When it goes to capturing the window contents by its HWND, I prefer this self-written VI (based on WinAPI calls).

Get Image By HWND.rar

And I'm using it that way.

Maybe in alvise's case it will suit as well - the chances are slim, but real. 🙂

Note also: the CLFN's in Get Image By HWND.vi are set to UI thread now, but it's safe to set them to any thread, if desired.

Then it should be that HCNetSDK.dll draws on the window canvas directly, not dealing with any related objects. I don't see, how you could easily intercept the data. If you are serious about HikVision image processing in LabVIEW, you'll have to return to the callback attempts.

You forgot brown error wire. 🙂

14 minutes ago, alvise said:

you suggested the method used with VLC

No actually. Only this piece.

Ok, try then to replace this NULL Handle check with another one shown here: https://forums.ni.com/t5/LabVIEW/How-to-extract-image-from-VLC-active-x-to-LabVIEW-image-JPEG-or/m-p/4117244#M1187715 Take a look at the condition below "Check to see if the Image passed in exists." comment. If that also is of no help, then you need to search for another way of getting the image (say, save a snapshot to the drive first and read out the file second).

28 minutes ago, alvise said:

Any ideas what to do now in this situation?

Your diagram still doesn't look like I'd like to see it.

- You read the image in frame named "1", whereas it should be named "1.." (with two dots after 1), that means "greater than or equal to 1"

- The other frame should be named as "..0" or "0, Default", that means it will proceed values other than positive ones.

Do you receive the same error message after these modifications?