ShaunR

I think that's a bit harsh. He's a programmer, not a developer. What's the difference? A programmer writes functions that they are told to write. A developer writes solutions. A team will usually have at least one developer designing the solution and producing functions to give to programmers to implement. the problem with these teams is that the programmers get blinkered into "follow ze orders" instead of thinking for themselves. When you look at the LabVIEW Architects exam, you are developing the solution and decompose it into VI's which are often non-functioning. Those functions are implemented by programmers. You (personally) can do both (a one-stop-shop for solutions) but the transition from a programmer to developer is a slow process of growth and mind-set. However. Can you imagine the carnage of responses and "assistance" if this was a Linux forum?

You were already given it, no?

Awesome. Congrats.

I still don't quite understand this. Windows Handles are indexes into the Handle Table and is limited to something like 16M

The use of the caption for text presentation instead of the label is, perhaps, a little understated as to it's usefulness. You can use labels to identify single controls or groups of controls by using a consistent naming convention (e.g. Button_1, Button_2 etc). By adding the VI name, this becomes a method of name-spacing controls across an entire application. This was how PassaMak (an old, on-the-fly, translation tool of mine) operated and how the Panel Settings Example above is supposed to be used.

The SQLite API for LabVIEW had a feature for that. Very easy with a database. I suppose you could do something similar just by saving and loading a particularly named JSON file.

Anything you are no sure of, just open in a VM first.

Yup. NI read these forums too

We don't know what the OP's competence is in C/C++ - only LabVIEW. Additionally. He may have access to very competent C/C++ programmers within the company. All I'm saying is that, generally, LabVIEW is pretty slow when it comes to computational functions when compared to C/C++. So if he thinks that he can get better performance from a DLL, then it's valid to try things out or to figure out how to tell another C/C++ programmer what interface to their code would be better for him. If I had 10 minutes in a room with the developers of OpenSSL 3, there would be a few choice words and ringing ears at the end of it

That's not strictly true. There are some standard situations where LabVIEW is extremely slow and one of those is for computational functions. As an example. Hashing, encryption et. al. is orders of magnitude faster using OpenSSL than native LabVIEW. I don't know much about AI but I do know it is computationally intensive. Amen to that

Yes. LabVIEW owns it, not the DLL Ready to take the training wheels off (orange nodes) and run in any thread (yellow nodes)? Me neither. I can understand wanting to figure out how to interface to external DLL's but this seems a lot of effort for no reward. Passing a LabVIEW array to a DLL would be more useful as a learning exercise and a lot easier. Maybe it's just that he is moving from C/C++ and so is trying to do things they way he always has. I think we (as LabVIEW programmers) often forget what an enormous paradigm shift it actually is.

I still think this is possible. It's been a couple of years since I wrote C++ so will have to brush up to investigate.

This is good practice. Depending on what version of LV I'm using, I also usually use the flush event queue with either a time (1 sec) or number of events (10) and raise a warning (dropping frames) if it is exceeded. This makes sure you don't run out of memory.

Yes. That's why I was thinking about Varidics being told what function to create with a "creator" function (the cluster) defining it.

so your objection isn't the callback, per se. It's the PostLVUserEvent data type which is a void*. What if we fixed the data type to be an array of U8? That is the most common usage for getting data from callbacks and most types can be massaged into an array of bytes. I was thinking more of a Sunday afternoon while drinking a Negroni

I was wondering if we could have a generic solution for callbacks using Variadic functions/templates or maybe the Pack Expansion. We could prime the callback with a call to set the callback parameter list (cluster?) and target (the dll) we need and then apply the callback which has a PostLVUserEvent in its function body.

NI have just put the distro's behind a paywall. Those links will die.

Open source freeware and torrents have a similar ethos. You should at least understand that. Why do people help on the forums? What do they get out of that? What do you expect to get for your invaluable help here? Time is money, right? BTW. They are rhetorical questions to hopefully instill a little cognitive dissonance at your out-right rejection of torrents and similar. I think it's very clear from the posts here about accessing old versions the service these torrents could provide IF NI was happy with it. You just seem to think it would never happen because, what? Game theory? (Moon Knight episode one has 2117 seeders ATM)

Who says you don't get something in return? Someone makes LV 2020 ISO available and maybe downloads Moon Knight. Don't tell me you are new to this torrenting malarkey. I have a 12TB Nas box. A few hundred gigs of karma is nothing.

Looks like The Pirate Bay is going to become NI support.

As Rolf says. No! They will give you chance to figure out how to call functions without everything crashing and what needs to be initialised before you call any functions. They are simple functions so a good starting point. You have to walk before you can run.

OK. You are clearly drowning in the learning curve so lets get back to basics. You need a strategy! You have a working example (Preview.cs). Do you know how to compile it? If not, that's your first task-get an executable out of the example code. This will be your golden standard for checking your program is doing things right. Next. That example saves a file in the callback (实时流数据.ps). You may have to change the filename to an ascii one for LabVIEW to read it as LabVIEW doesn't support Unicode. You should be able to read that file from LabVIEW (after is is closed). That is the raw data that you would normally get back from a callback. Read that file in LabVIEW and figure out how to interpret it (it's a byte array [array of u8]. The callback is public void RealDataCallBack(Int32 lRealHandle, UInt32 dwDataType, IntPtr pBuffer, UInt32 dwBufSize, IntPtr pUser) This callback (for a .NET Assembly or a similar one for C[++]) would be where you put the PostLVUserEvent instead of saving to a file. Your problem at that point is telling the callback to use a LabVIEW refnum. Don't worry about putting that in for now, we can talk about that later. Once you get that far, you will be a long way through the learning curve for this API but just by reading the file you can work on presenting the data [U8 array] in LabVIEW (you will feel progress) while you think about how to get the data directly. Look to see what the example code is doing with it and replicate it in LabVIEW. There are also other functions that you can call directly from LabVIEW that don't require a callback (e.g. NET_DVR_CaptureJPEGPicture & NET_DVR_CapturePicture) and take normal parameters that you can pass directly. Get those working from LabVIEW (more progress)

Callbacks is the one instance when I would suggest a .NET solution in LabVIEW (in the absence of anything else) for all of these reasons and everybody knows what I think about .NET

Be afraid; be very afraid Generally, there is no concept of a pointer in LabVIEW. LabVIEW is a managed environment so it is more like .NET. You don't know here it is stored or even how much memory is used to store it. The CLFN will do that out-of-the-box .Yes. Because you don't know where it is for the lifetime of the variable.

You are playing with fire. Ownership is key. DO NOT manipulate pointers in LabVIEW-period! You either manipulate data by passing it to a DLL (like an array where LabVIEW owns the data) or you provide functions to manipulate data (where the DLL owns the data - where is your freeing of the pointer allocated inside the DLL?). LabVIEW has no ability to know what a DLL is doing with memory and vice versa. You must also take into account the pointer size. (32 bit LabVIEW or 64 bit LabVIEW). For some types, this is handled for you (arrays, for example) others you will want to use the Unsigned/Signed Pointer sized Variable (for opaque pointers) and pass that BY VALUE to other functions. Look at the Function Prototype in the dialogue. You will see the C equivalent of the call. Note that you do not seem to be able to do things things like int32_t myfunc(&val). Instead you have to use "Pointer to Value" and it will look like int32_t myfunc(int32_t *val). If you are trying to manipulate pointers, you are doing it wrong and it will crash at some point taking the whole IDE with it.