LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Open VI reference from bytestream?

Solved!
Go to solution

The "Open VI Reference" function either creates a reference to a VI already loaded in memory or loads a VI into memory from a file path and returns a reference to it. My question is whether there is a way to open a VI reference from a bytestream/string in memory, i.e. something like a virtual file without having to go through the OS's file system. "Untitled" VIs that haven't been saved to file should behave like that, meaning they are represented by some data structure in memory without ever being files in a file system. Maybe it's somehow possible to load the contents of an existing VI (e.g. previously read as a bytestream from a file) into an "empty" file-less VIs through scripting?

 

The background is that I'm going through a large collection of (say, unknown) VI files in order to inspect them with VI server functions (open VI reference and so on). The problem is possible file name collisions with other VIs already loaded into memory (same file name, different path and content). I know this could be solved with proper name spacing (libraries) but that's not always an option. A workaround at the moment is to check whether a VI with the same name is already in memory, and in that case rename the VI file to be inspected to some unique random name, open the reference and rename it back after processing (or make a file copy with a unique name into a temp folder in order not to alter the original file). I was wondering if instead of messing with the file name or creating a temporary copy on disk, I could simply read the file contents as a bytestream and open the VI reference from that with the VI existing purely in memory.

0 Kudos
Message 1 of 7
(3,355 Views)

Even if they are not saved on disk, "Untitled" VIs still have unique names accross their owning application, and that would also be the case if the "load from bytestream" feature your are asking ever existed. Any VI loaded in a context must have a unique name in its context (more precisely the fully qualified name must be unique, meaning by taking into account the library namespaces).

 

You could use this VI by @paul_a_cardinale that creates a new private context/application.

You could try to load all your VIs in your normal application (My Computer), then in case of name collision, create on-the-fly a new context and open it there, and iteratively create as many contexts as needed until all VIs are loaded.

 

One side effect though may be that any class loaded in multiple contexts will be locked for edits...

 

Regards,

Raphaël.

0 Kudos
Message 2 of 7
(3,331 Views)

@raphschru wrote:

Even if they are not saved on disk, "Untitled" VIs still have unique names accross their owning application, and that would also be the case if the "load from bytestream" feature your are asking ever existed. Any VI loaded in a context must have a unique name in its context (more precisely the fully qualified name must be unique, meaning by taking into account the library namespaces).


Yes, I'm aware that "Untitled" VIs have unique internal names in memory. If there was a "VI reference from bytestream" feature, it could simply usa another "Untitled" unique internal name or get a unique name supplied from the caller. In that case I would just generate a random string as the temporary name, just as I do at the moment when making a temporary copy of the VI file.

 

The programmatic creation of a library context looks like a good solution if the AddFile method accepts unopened files as paths. I'm just wondering whether this will modify the VI file added to this temporary context, which I would like to avoid. Won't it add the temporary library name to the VI file's library list (LIBN resource)?

0 Kudos
Message 3 of 7
(3,312 Views)

@Novgorod wrote:

The programmatic creation of a library context looks like a good solution if the AddFile method accepts unopened files as paths. I'm just wondering whether this will modify the VI file added to this temporary context, which I would like to avoid. Won't it add the temporary library name to the VI file's library list (LIBN resource)?


It does not create a library or any projet item. It creates a VI Server "Application", such as the one associated to each target of your project, but this one would not be associated to any target. Then you can feed this application reference to the Open VI Reference node to open the VIs that have the same name as other VIs already loaded.

0 Kudos
Message 4 of 7
(3,299 Views)
Solution
Accepted by topic author Novgorod

There is this deprecated method:

paul_a_cardinale_0-1725303821696.png

 

Message 5 of 7
(3,280 Views)

You could always use an alternate context (it will have its own isolated namespace):

paul_a_cardinale_0-1725304077776.png

0 Kudos
Message 6 of 7
(3,278 Views)

@paul_a_cardinale wrote:

There is this deprecated method:

 


Wow, this is exactly what I was hoping it to be! The VI name property is "Untitled XX" and the path is "not a path" - perfect. The buffer is just a VI file bytestream. Let's hope NI won't patch it out 🙂 ...

 

Of course the separate context method is the cleaner solution long-term.

0 Kudos
Message 7 of 7
(3,251 Views)