ShaunR

Start a new thread and tell us then.

Maybe it's your lack of imagination? It is at the intersection of IT. Cloud services are under the IT remit and new servers for each client aren't hard with VM instances. Talk to your IT and give them an instance template and they can spin up hundreds for you. Then just add links in your intranet pages. Of course if you really don't care about your clients data you can spin them up on Amazon Web Services or the Google Compute Engines.

I think this is NI being responsible. Should you really be putting your customers' data on a 3rd party servers? If a customer is happy for that, then they can buy the service with full knowledge and give you access, but I don't think integrators, contractors or developers should be using it for their clients.

I think I've come across something similar with named clusters and am not sure what the behaviour should be (but with events). The behaviour is difficult to describe but I'll have a go. I have this setup. I'm not sure how the name "Data" is chosen for the scaler type name, but it's the name of the event terminal on the VIM so that makes sense if you have to call it something. Deleting the Uint32 wire and wiring the cluster works sort of as expected with the ""Data" changing to "String" (i.e. one of the cluster elements). Popping up on the event data terminal reveals both cluster elements (String and UInt32). So far so good. Deleting the cluster wire and reattaching the Uint32 however doesn't change the event data terminal (remains as "String")and the VI is broken. BUT, popping up on the terminal shows the correct data type in the menu, which can be selected, and the VI is once again not broken. Note also that replacing the VIM yields the correct event data terminal type (called "Data"). OK. Not really a problem, but unexpected. So. Reattaching the cluster we get back to the second image (event data terminal is "String") as before. Now I change the cluster element name from "String" to "Value". But the event data terminal doesn't change, it remains as "String". The VI is not broken and popping up on it reveals the previous items "String" and "Uin32". The name change hasn't propagated nor can it be selected from the popup menu. It is recoverable, though although I'm not sure what would happen if I tried to generate the event with a string named "Value". Deleting the cluster wire and reattaching causes it to appear in the menu popup (broken VI with "String" as the event data terminal) so selecting it brings us back to a functioning VI. However. If instead of just deleting the wire, the VIM is replaced completely, then everything changes as I would expect (the "String" event data terminal changes to "Value" and the VI is unbroken with the correct popup menu entries). Arguably just a another example of "left handed scissors" but the cluster name selection and propagation strikes me as another manifestation of what drjdpowell is describing. srevent.vim

Just because you refactor something doesn't make it a "new feature". And just because something is buggy, doesn't mean the the bug-fixed feature is different. The history is laid out in the thread I linked including discussion about the ""Type Enabled Structure" (which, although buggy; appeared in LV 2016, IIRC) and some thoughts on addressing our requests for usage by JeffK (including polymorphic VIs). Even the file extension has remained the same (shouldn't it now be MVI?). I would accept it as being a "newly supported feature" from 2017 onwards, though. It wasn't a joke but now you just seem to be gaslighting us. Malleable VIs are clearly the productionised implementation of VI Macros and I doubt "Malleable VIs" would exist without us discovering VIMs and discussing it here (they'd been around since about 8.2). That's not to be dismissive of all the work that has gone into getting them working properly - which is undoubtably immense - but some of us are just getting round to using the "Malleable VIs" in anger and of course the first thing we will do is go back to the code that we wrote for VIMs to find out any new limitations and what's been fixed.

Yes. It's a distinction without a difference. GregSands found it, the community investigated it and malleable VIs were the productionisation of it.

Both of those technlogies are half-way houses to the real requirements. I think that's why they are left-handed scissors (when the requirement was a guillotine). LLBs are far better than PPLs, they just don't have namespacing and how does NI actually create new controls? I like the term, though. I wouldn't knowingly buy left handed scissors and if I accidently did, I'm more likely use them purely as a prank. Perhaps extend the notion. A left-hand drive car where one drives on the left side of the road - can't see what's on-coming when you overtake but when something does; it's a disaster. Just never overtake.

Merry Xmas:Symlink.llb

Yeah. but it worked n 2009

I think we've articulated the goal well enough. However, a VIM doesn't necessarily have a reference like Queues et. al. so I'm not sure there would be an "uncomplicated" first order solution for it even though it's a kind of natural progression from singular VIMs to libraries of VIMs. In theory, the second order solution is to use those primitives internally since they have that behaviour which should propegate out but I was unable to see if that worked with DVRs and trying queues didn't illicit the behaviour.

Seems VIMs can no longer be used in polymorphic VIs either. I don't think this is a good idea. The VIMs I've played around with (before the type case structure was introduced) relied on at least one terminal having a type which would dictate the undefined types due to the nature of the internal polymorphic VIs (like a Queue or DVR). This is why I was trying to get a VIM to create a DVR which "should" define the type across all connected VIs which would solve this problem. In a nutshell, I'm expecting this set of VIMs (rightly or wrongly) to behave like the Queue, Notifier et. al. primitives when the Enqueue and Dequeue element terminal is unwired.

VIMs have to be inlined now therefore:

Never mind. It seems that you cannot have DVRs inside VIMs any more.

If you were to use a DVR (or the user supplied DVR) and put the reference onto a single element queue inside the ViM. Wouldn't you get all the type checking and polymorphism for free across all the VIs without all the type cases?

I can't find them in the examples finder (tried a few different words). The button on VIPM shows the directory with them, though. FWIW. I hate the example finder. You neeed to know the right words for what you're searching for and it's a lot of clicks and typing to get there (ignoring the excrutiating pain of actually creating the Example Finder special files). It's much preferable to have them in the same pallet as the VIs; as you had originally. They need to take that requirement off of the tools network checklist.

The examples were missing when I installed the VIP package so it took me a bit of time to figure out why wires were broken (see bottom row of VIs). The rows above are what happens when the correct data type is applied to the "Add To Buffer" Is it possiblee to to make the "Add To Buffer" select the correct instance depending on the "Create Buffer" data type?

It's the other way round. You include the files contained in an LLB in a lvlib. You end up with two files, the lvlib (XML description) and the LLB (the Vis).

They will be vetted and approved by their respective governments. The problem as I see it isn't limiting execution to signed code, it is who has capability to create and control the keys. "Derived keys" are weasel words for backdoors. But I see it as worse than that. These proposed hardware keys only limit what you can run, not what they (M$ et.al.) can run and they are major players in my threat model. Remember the the Clipper Chip? Or the Apple "Kill Switch"?. These kinds of technologies are packaged as "security" but give the corporate behemoths an inordinate amount of control over your devices. The technology already exists for self-signed secure boot. and a similar route for execution is far more appropriate. You don't need to trust anyone else but yourself (by that I mean your company) - you can't outsource security! Nope. I don't trust them as far as I can throw them. I go to great lengths to mitigate exfiltration of information to the likes of Google, M$ (i refuse to use Apple products) etc. I block all sites that are behind Coudflare (which is a MITM) and I use my own servers for things like Git, SVN, Jenkins etc. I realise the current trend is for online services (e.g Github) storing all your data but this is folly IMO. I may have to use a M$ OS, but I can and do limit their ability to leverage their indisdious telemetry and who has Driver Signing turned on? The annointed ones? China has it's own Certificate Authorities so good luck with that if your data gets routed through their servers. Cert Auth is a poor solution that only really works for the man-in-the-street because the root certificates are routinely distributed with browsers (Windows updates it's store once a week, IIRC). When did NI last update their users' LabVIEW CA file for the HTTPS Vis? What exactly is NI's policy on this and where is it documented?

Signing is great but just be aware the weakness is key distribution. Not so much a problem with physical distributions but a concern over the internet depending on your threat model.

Chinese, Russian and North Korean companies too? Excuse me if I'm not entralled by allowing M$/Intel/Apple/etc backdoors or control of what I can and can't run in an age where computers are always connected and OS telemetry is rife. I reject this dystopian sales pitch for "security" which is nothing more than a hardware version of Certificate Authorities aimed squarely at market control.

Hmm. Just looked at my creatfile in the Zip Library. Seems I used "FNewRefNum" rather than a cast so I was obviously talking out of my backside. I guess I remembered all the stuff that didn't work rather than what did.

Is that a consequence of using an intermediary DLL and "adapt to type" on the CLFN? Using the type cast at the LabVIEW level should mitigate this for TCP and file refs. Depends on what you want to do with them. Deleting the target? If the LabVIEW delete function is based on deletefile (and I can't remember off hand if it is because it doesn't take a filename), then deleting the target depends on the FILE_FLAG_DELETE_ON_CLOSE when calling createfile. I'll have to go back over this because I figured it out last time with the Zip library but for release, only needed long filename support (and even then, only for extraction). I added the methods to create and read the symlink attribute with a view to adding the functionality later after some bug reports. IIRC writing symlinks wasn't much of a problem, reading them were a little bit harder but shorcuts were a pain which I decided not to do. The file read and write only take a handle and don't care about most of these issues. Of course I haven't concerned myself with Mac and Linux.

This is what I deduced for Windows. (It was a while ago, but this is what I recall) Casting the refnum to an integer reveals the same value as the windows file handle (from Process Hacker). Casting it back enables using the native LabVIEW functions. Casting the handle from CreateFileW to a LabVIEW file refnum also allows usage of all the native file functions(including delete) but the LabVIEW delete function isn't symlink aware (treats it as a normal file). The LabVIEW file functions just seem to be primitives of the windows functions *A (which is what can be seen in the imports table). <- this is rubbish It'd be nice if someone from NI confirmed that the file refnum is or isn't just a LabVIEW version of the windows file handle (perhaps with a reference count) but that's all it seems to be. I think it is like the TCP reference in that regard.

Nothing what. It's just an interesting data presentation showing the rise and fall of languages over time. It's just a shame LabVIEW isn't on there.

Most Popular Programming Languages 1965 - 2019