dadreamer

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.

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.

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

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

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?

The OP uses LabVIEW 32-bit.

You don't need this! This was just to demonstrate that when the Image object is initialized, no errors occur on reading after. My bad, I didn't realize that when answering 😃 Then you should move that PictureBox reading into a parallel While loop and see, what will happen. This way you're not synchronizing the threads and may miss some data frames though (due to different rates of the loops).

You happen to read the Image object, when it's not instantiated yet, hence you receive 1172 error. You need to read it out only after your image data is loaded into the PictureBox control. Try to add your code piece into the Value Change frame plus add a simple NULL check. That should work, but if not, then you need to find a way to synchronize image write thread with image read thread (with callback that would be easier).

Was it ever browsable? As I recall I've never been able to browse softlib directory. Maybe because I often don't login to NI site or don't have a valid SSP, when trying to fetch the server content. They might introduce a hash system for the files as applied on many file sharing services (to force visitors to watch the ads). Then nobody would be able to browse through their servers. But it'll break many links, which are settled down in the manuals and other papers.

There's something with your browser/connection/cookies/firewall/etc., because I downloaded both archives right now and nothing interrupted me. Anyway even if the links go dead, you know who to ask about reupping. 😉

If you want to manipulate array pointers directly on the diagram, why not use convenient Memory Manager functions such as DSNewPtr / DSNewPClr? You may call them through the same CLF Nodes as you already do with MoveBlock function. Just allocate enough memory with DSNewPtr, copy the array contents to there with MoveBlock and then do what you want. Or, if you prefer hacky ways, you could use internal ArrayMemInfo node and process arrays "in-place", without getting extra copies on data transfers. In the latter case it's necessary to realize that the pointer will be 'alive' as long as you pull the array wire through the structures. At the moment you decide to drop that wire somewhere, LabVIEW wants to optimize your code and the pointer becomes invalid or occupied by something else in the next structures. But, as it has been said above, LV native yellow nodes should already be optimized and should satisfy your needs in most cases. If not, then process your array in DLL entirely and give that array back to LV, when it's done completely. As long as you are in the DLL doing something with the data, the array pointer should be fine. upd: You changed your snippets and seem to use Memory Manager allocation functions now. Still I don't get the grand design of these experiments. Maybe I should wait a little. 😀

I managed to check that on few machines with few LabVIEW versions, including 2011, 2013, 2018 and 2019 (32- and 64-bit) as I seldomly use subpanels and never ever wondered about how the VIs are embedded. Looks like this is the case, when an old-fashioned MDI relation has an advantage of providing handles to operate the windows on OS level. Sure, you know, that it could be done with SetParent function. But there are a lot of disadvantages and odd issues too, so it's a doubtful method. As I remember, there's private Open In Native Window method, that tries to supersede an obsolete Open In Window method. The latter works well in LV8.5, but doesn't work absolutely in LV 2009 and higher. But the new method doesn't work anywhere at all! I have spent more than a week trying to understand why. Still sort of a mystery, but I think there was a mistake made in the code, when introducing the new method. There's something wrong with the window styles and that's why the child window doesn't get embedded into the parent window. Interesting puzzle but almost an off-topic here. 🙂

Maybe there's something I'm missing. I tried to debug Rolf's example a bit. It appears that I'm getting zero HWND for the subpanel VI as well! Could it be that NI changed the way VI's are inserted into the main VI? WinSpy++ doesn't even show the window of "Empty.vi" anywhere in the windows hierarchy. I'm using LabVIEW 2019 32-bit right now. Seems to need more testing on different LV versions. Moreover Get Last Error.vi was reporting an error in NET_DVR_GetErrorMsg configuration. This function has the following prototype: char* NET_DVR_GetErrorMsg( LONG *pErrorNo ); But in the CLFN settings pErrorNo was passed as value, not as pointer to value. After the fix it started to work as intended.

Add SuperSecretPrivateSpecialStuff=True line into your LabVIEW.ini and you will find it. 😉

There is a nasty effect, when this is happening. You may notice, that the image on your panel indicator starts to lag behind what is going on before the camera. Easy to verify with moving the camera or the objects in front of it. Event Inspector window is of help here as well, showing that the events are being accumulated and not being processed in time. When no need to view or process each and every frame of the data, I usually introduce a boolean flag, that could allow or deny posting from the DLL to LabVIEW. Most of the time the flag is False and the callback is idling. When I need the data to process, I set the flag to True, grab some frames and set it to False right after. Usually there's no more than a few cameras in the system and this works well.

I can't speak for anyone else, but from what I saw, Rolf's example should work "as is", without any callbacks or something extra. I can't say, why it doesn't work on your side. But it should. Well, you have two options here. You may try to figure out, why Rolf's example doesn't want to work, and fix it on your own. Or you could write the callback DLL and integrate it into your previous samples (from page one of this thread). Of course, if you can fix Rolf's example and write the callback, then you may combine two options into one and get best example for that camera. Don't insert any C# code, just try to compile it into a library and report the progress. You should receive a standard DLL, that's exporting two functions: SendEvent and g_DataCallBack. Check that they both are present.

What do you mean in this question?

You are right. By the way that is the example, that I used a while ago to study PostLVUserEvent just like you do. But you don't need the string manipulations from there. You're going to pass pBuffer pointer to LabVIEW with PostLVUserEvent function inside your callback and you should be done. Looking at your C code I see, you're doing more or less good. But you don't even need to implement the main function, because all the work with the cameras is made in your LabVIEW application entirely. You could remove that code at all. Besides the callback function you'll need one extra helper function, that would set your User Event refnum to some global variable in your DLL. That's needed, because when you'll want to call PostLVUserEvent, you'll need that refnum and you could take it out of that global variable. Something like this: #include <stdio.h> #include <iostream> #include <time.h> #include "Windows.h" #include "extcode.h" using namespace std; LVUserEventRef *pUE; void SendEvent(LVUserEventRef *rwer) { pUE = rwer; } void CALLBACK g_DataCallBack(LONG lRealHandle, DWORD dwDataType, BYTE *pBuffer, DWORD dwBufSize, void *pUser) { //your callback code here // ... //PostLVUserEvent(*pUE, (void *)&pBuffer); is here as well } Likely will require some small fine-tuning like adding extern "C" { ... } to escape functions name mangling.