Leaderboard

UPDATE: These first few revisions are more or less broken. The first fully working version can be found here. 8 Years ago the first version of the XNode Manager was posted to the code repository, and it hasn't seen an update since 2009. Being a fan of XNodes, but knowing that the XNode Manager is pretty limiting because of its age, I set out to make a new version with similar functionality. I didn't spend too much time on it, and I don't think it replicates all the XNode Manager functionality, but it does have some major improvements. The XNode Manager had a blank XNode, and blank Abilities that it just made copies of. This is fine but then the abilities and XNode are quite old. There were many new Abilities added since version 8.2 and you can't add them using the XNode Manager. My XNode Editor reads your LabVIEW resource and populates the list of abilities to create from the ones that are possible to create. Then VI server is used to create the XNode, State control, and Abilities. This sets up the connector pane like it should and should work with all future versions of LabVIEW, until NI changes something that breaks it. Be aware this uses several private functions, and several undocumented features that could be potentially bad. I did a decent test to make sure memory leaks weren't a problem and I made several XNodes and Abilities and it seems stable. But at the end of the day if it blows up and crashes, don't be surprised, you've been warned. Saved in 2013, but could probably back save earlier if requested. If I get more time I'll add some features, and add it to the Code Repository. XNode Editor.zip

Okay so I did get a solution for my use case. One of my new favorite private functions is the Save VI as Buffer. It performs the same save operation that a VI normally does, but returns the stream of bytes that the file would be, had it been written to disk. Luckily there is also a Save Library as Buffer. So using these functions I was able to get the VI and project buffers, then save them to disk using the write binary file. The only modification I needed was to edit the library buffer stream, modifying the XML to include the relative path to the member. Since the member hadn't been saved yet the path wasn't stored in the project buffer. After that I needed to close some references, and it seems to work.

Oh it's not hard, it's you just need to use unconventional tools. A while ago I posted a bunch of VIs that open up the VI file structure. Normally you provide a VI as a path, then it reads it, analyzes it and tells you what blocks are in the VI and at what offsets. This can then do things like read the VI description, VI icon, and a bunch of other things without opening a reference to the file. This same code could be used to analyze VI files without LabVIEW too. Anyway so I made a couple VIs one with a block diagram one without, and looked at what blocked were missing then found a couple that start with BD and assume that has to do with the block diagram. So attached is some code. Open Perform Test which will have two static VI references in it. One to a VI with a block diagram one without. It will then perform a save VI as a buffer, then using that buffer will find the blocks, and look for the BD ones. I also built and EXE and it also worked from there too. One downside is the VI without a block diagram was saved in 2013, so this exact test only runs in 2013, but if you provide your own VI without a BD in whatever version you have it should work. Couple of undocumented features being used here by the way. Block Diagram Test.zip