hooovahh

GRRRRR, so many work arounds. I really didn't want to resort to having to parse the XML. NI has the functions for navigating XNodes just like libraries but they all either don't act the same, or don't work at all without a license. On top of that they some times use alternate names for some abilities, like how OnRefeeChange might some times be called RefeeChanged and the right one needs to be in the right place or things don't work. Also some Abilities have other tags like NI.XItem.RuntimeAbility. I wanted to use the Add Ability function, seems like a great idea and takes care of a bunch of things in one function. But that doesn't work, so you either bring along templates of each ability or you copy them from the resource folder. But then why do they include Fatal Error Out? Then I found that neat little function that will tell you a Ability, given a ProjectItem reference. But guess what? List Members doesn't work without a license, so no getting members for this function. That also means no finding what the State control is. So at the end of all this I'm 90% there but compromised a lot of the modularity, and have to compromise more doing more XML parsing... So here is what I have. It does make the XNode, and makes abilities. But doesn't replace the state control, Fatal error might be there and need to be deleted (the broken arrow will tell you this) and the list of existing members in the listbox doesn't work. XNode Editor Tool Not Quite There.zip

Yeah I made an edit basically saying you can resave the XNode and it fixes these minor concerns. I then had issues with the Add Ability method which I think is also restricted license issues. I also saw some oddness when trying to open a XNode that doesn't have a control, it some times would add the State and some times wouldn't. And then I even saw times when using the Add Ability would return an error saying it can't add that type of ability, but I know it can.

Uh well sorta, I posted an XNode Editor here: https://lavag.org/topic/19069-xnode-editor/ And despite the most likes I've gotten on a post (currently 9) it doesn't actually work because of a missing XNode license. But the code for saving the library, and VI as buffers, then writing them individually does work.

Well sure but I wanted to avoid this technique because when LabVIEW 2015 comes out, this will make XNodes in the 2014 version. Just like how now XNodes made with the XNode Manager make 8.2 XNodes. I thought that by using the built in invoke node I could make a new XNode that was for that current version of LabVIEW. But it looks like this isn't possible, and your method, which is essentially the method used in the XNode Manager, is the only way at the moment. EDIT: Actually it isn't that bad, if you open a blank XNode, then perform an open, it automatically adds the State Ability, and saving the library fixes things nicely.

Well it hasn't changed since version 5 or so. This block format is likely here to stay. What may change is what the 4 letter abbreviations are or stand for. I assume if it starts with BD is is for the block diagram.

So what I usually do is get the calling VI reference using the call chain, and get the HWND from that. I'd prefer this over getting the top most VI call because that could be a launching VI that has its window hidden. This of course assumes that the VI calling this dialog is currently showing a VI. Of course there is also the desire to sometimes have it be model for the whole system (HWND = 0). This is what I've always used on my Windows Dialog, but again that needs its own dedicated subVI terminal input on every interface VI.

Oh...well this is useless isn't it? I guess Uh...well back to the drawing board sorry. Maybe I'll look into updating the current method of the XNode Manager instead. That sucks. Okay looks like I'm learning things others already knew, but all the abilities and some utility VIs can be found here. <LabVIEW>\resource\Framework\Providers\xi I'm going to look into leveraging these to make the XNode Editor work again.

While I don't think that was exactly what I'm talking about, I think the spirit of it is true. Basically you have a XNode that is made to be an interface for a subVI. You tell the XNode what subVI to interface with and it draw the icon, and creates a block diagram node with inputs and outputs. You can then double click the XNode and configure those inputs and outputs to come from like the terminal or networked shared variable. I suppose theoretically you could make a generic XNode once, that you can insert any VI into, then double click and tell it what rules the XNode's inputs should have. Then that copy of that XNode will behave with those rules when wired. The problem I see with this is the settings for that XNode live with that XNode, and could be edited by the user of the XNode. In general this is not something I would want. When I make something like the OpenG Search Array, I want those settings to be a thing that is the same for every copy of that XNode. Instead of making an interface to a subVI, I'd prefer making a new XNode for each function. But maybe that's because I'm in the old way of thinking, and those settings could be somehow saved with the template VI. I'm still not convinced this would be the right way. It would almost be like making a single wrapper for all adaptive VIs of this type, and I'd rather have a wrapper for each function, so that if custom things need to be done, they can.

Well sure but...well I'll need to check it but I don't think it can always work like that. Say for instance I take one of the OpenG array functions, the Search Array. You give it a 1D array of some data, and you give it a scalar of that same data type to search for and it returns the array of indexes that match. In this case if I set both the Array, and the Element Data to adaptive then that means that both inputs accept any data type. The Array input could be a cluster, and the Element Data could be a variant and it would wire up just fine without any broken wires. But the XNode VI that is scripted (the template) will be broken, and the error returned won't be clear to the user of the XNode because the error will be coming from within a VI that they didn't know was scripted and they can't see inside. Adaptive is great if you really mean you accept any data type (like my Variant Repository) but seldom do you really want to accept anything. You may want rules like this input must be an array, and this input must be a scalar. Generics would similarly need some kind of bounds on their inputs.

Thanks you and this is nice, but I'm guessing this only works if the full LabVIEW development environment is installed, because this relies on that ever so important REdLoadResFile call Jack mentioned earlier. Still this is helpful and I will look into modifying my VI File Structure code in the future to have that option, since it probably is less error prone and more flexible than my manual method.

So I was thinking this. You run Tools >> Create Adaptive XNode (don't go looking it doesn't exist yet). There you provide a path to a template VI. Using scripting we read the terminal inputs and show them to the user in a window asking how their the inputs should be allowed to accept various types. I was thinking there is a list of the common data types, (string, boolean, path, etc) or limit to an array of common types (string, boolean, etc) or a cluster where limits could be set. Or have an option for accept all data types. There would probably need to be some additional logic like "Input 1" can be an array of any size of any data type, but can't accept scalars, and "Input 2" must be the same data type as "Input 1" but with one less dimension to the array, or one greater or whatever. After specifying the template VI, and what rules each input should have, you choose to set which outputs are adaptive. These will change based on the code in the template so I don't think additional rules need to be set on the outputs. Then you hit "Go" and an XNode is made, (copying a already made one to be easiest) which sets the template VI, and sets what the terminal behavior is by editing the constants in the GetTerms, and AdaptToInputs abilities. For more control I thought about having a blank VI that could be edited which did additional operations on the VI which is ran after the GenerateCode. There are a few times when I needed to do more than just drop in a template VI but also needed to set some block diagram constants based on the input data types as well. Then what you have is a nice little XNode that behaves like a Generic, but is an XNode and gives control over how the VI can be manipulated as various inputs are changed.

Personally I didn't think Generics was the right approach. XNodes already do what Generics don't, or sorta did in some use cases, some of the time. My point is Generics had a subset of features that XNodes did. Edit time polymorphics exist with XNodes, along with a whole slew of other cool features. Why create another way to solve the same problem? Focus on XNodes and on making that interface robust, stable, documented, etc. Then using scripting you can write a utility that makes a "Generic" which is just an XNode. That is a challenge that we can accomplish today. Given a VI as a template, create an XNode that accepts various things as the input, and then automatically change the output. Whos up for the challenge?

That's what I thought too, but I do have those special keys and I don't have OpenBinaryLibrary. So not only did something go wrong, but it went so wrong that some features even more secret than the super secret ones have been partially exposed. It sounds like your code is royally hosed somehow. Probably some kind of error where the timeout case is no longer valid, and the events are then shifted by one, which caused your value changes to turn into something else they probably shouldn't be. Hope you have source code control. I'd also bet that a repair install of LabVIEW will fix any new VIs made, but doubt it will fix any VIs saved that were in this broken state. You're probably going to need to contact NI for any real support. But thanks for sharing.

Very neat. Yeah I'd suggest making wrappers for each of the basic button examples you showed. The goal in my mind is to have as few inputs as possible, and exclude using clusters if possible, as well as using enums when possible. But I think some controls in your case will need to be rings, where maybe it has defined values, or a custom output. And I'd suggest making default values for inputs valid, so that fewer required inputs are needed. In my experience following these rules help make interfaces that other developers can use easily. Cluttering up the interface with tons of options gets confusing to new developers, and giving them fewer options, with working default options helps them adopt it easier. I don't have much time to work on these but here is an attempt at cleaning up some of the code. Functionally it should be the same. I moved some functions into the private code and exposed only important things as public, updated the example to use the event structure, and wrapped the first three functions into subVIs with icons, VI descriptions, and in the minimalist process I described earlier. I don't have 2012 installed so I had to back save from 2013, I hope things didn't break in the process. TaskDialogIndirect Source Hooovahh Edit.zip

Yeah we'll see, my initial thought is these couple of VIs aren't going to have much of an impact. If I am able to make tools that make XNodes, then likely others are able to make XNodes already. This might make, making XNodes easier, but it doesn't make understanding them easier. For me that's done by looking at what other XNodes have been made, and there are a couple good ones in the Code Repository. I am interested too in the progress of XNode development from NI's side. They not only add new abilities but update older ones. Like the GetTerms for instance added new data to their terminals to handle "English Name". So they are making an effort to continue updating this technology, for their internal uses anyway.

If you need a real time system, then you need a real-time system. Windows is not an appropriate system to be able to perform actions on a microsecond timing. Heck I wouldn't rely on a Windows application to respond in 10ms consistently. Ever been using Windows and have the keyboard and mouse go unresponsive for a few seconds? What do you think your application is doing during that time? That doesn't mean there isn't other possible Windows solutions. With IMAQ you can configure the acquire to return all frames, which can be kept in an onboard buffer. So you don't need to get a new frame every couple of microseconds. Instead you can wait 10ms and have it return all the frames that it acquired since the last read then process those one at a time. Still I think you'll have a problem processing them faster then they come in. So you'll still probably have a run away condition, and so when you last read is done there will still be time when the previous frames still need to be processed. This type of system is only really safe if the capturing of frames is a relatively short time frame. Another option is just to log all the frames as they come in, then post-process. This won't have the run away issue but your test will take longer of course.

You know I kinda thought it did. Do you have a pre-made VI that calls that with the right inputs that you could share? Oh but that only works on a VI path right? I can load the Block Data from a stream of bytes, not that it wouldn't be hard to save to a temp file.

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

Yeah it can be a bit of a hike. You can look into sharing a cab? Or those Pedi-cabs might be out by then, better tip them well cause it is up hill.

Wow keep up the good work. Yeah I'd say the majority of LabVIEW developers still use 32 bit LabVIEW regardless of the bitness of the OS, but still the majority of the features are working in 32 bit LabVIEW. I don't think this library is ready for a package yet, it is still very early. When the time comes we can try to wrap these functions into simple to use functions, give it some pretty icons, and then package it up. I'm loving the progress, keep it up.

I realize this is 5 years old, but that method won't work for me. Imagine if you create a new XControl. When that XControl is made it creates 4 things to go with that library. There is the Data, Facade, Init, and State. Through scripting if I make an XControl it will make these 4 items and put them in memory. I can't perform a save on a member of the library, or the library because of the issue you described. But I also can't remove these items from the library. I tried through scripting and I got crashy-crash. Might have been my fault but after I disconnected the VI from the library then attempted the save of the library it all went bad. So I have private methods on, and I still don't know a way to save a library with unsaved members, that cannot be removed or disconnected from the library. Any thoughts?

Topic moved and renamed. In the future do this by using the Report to Moderator button, I just happened to be following this topic, not all moderators follow all topics believe it or not.

I guess I just got super excited when I saw a demo and didn't read the rest of the posts enough.