hooovahh

You can't do it the way you want. An array by definition means that every element in the array has the same properties, and only varies by value. This means each combo box needs to have the same drop down items. Now there are work arounds, like replacing the current items in a drop down with new ones as the user uses the control. So if I click on the second element I can change those items when it is clicked. I may have an example somewhere. It basically involves capturing the mouse down? event on the combo box then using that reference to set the items.

Hey my solution should work in RT, Windows, and Linux, with or without the IDE, inside or outside of an EXE, by passing in a VI reference. Just saying. (not certain about other platforms due to how the buffer is saved, but there are inputs to force it to Windows in which case I think it should work) But if NI improved those functions that would certainly be a better approach. Or if NI just saved the VI into a text file, or some kind of open standard, in which case looking for the block diagram using text would be trivial.

That's great if you already have an ability made and want to add it. It also doesn't do things like find the State control type def and replace them. It also doesn't set the allow run time. And you need to know the correct name of the Ability. But still you showed me one step that I could remove, which is when adding the file set the type to Ability VI.

The first post I made created the XNode and abilities using scripting. It would create the XNode, which is a library, then invoke the Add Ability where you specify the ability to add. Both the Create XNode, and the Add Ability don't work if you don't have a XNode license. Additionally List Members which usually tells you what items are in a library also doesn't work without a license. So I'm not sure what other scripting functions you could try from the project window. Just like with adding a VI to a project, you can't invoke a Create VI on a project using scripting. You first create the VI, then use the Add Item. And at this point we can't create the item, but we could probably add it if one was made. The only other hope I had was to see if the Project Provider Framework was used to implement the XNode creation in the project window. It wasn't, that would have been too easy. Just so I'm not completely defeated I figured I could at least post a XNode which has all the abilities on it for a version of LabVIEW. So if you want a 2013 XNode attached is one that has every ability. If you don't like the name, you can open the XNode in LabVIEW, and perform a rename which will resave all the members. That part does work without a license. To remove an Ability delete the VI, then open the XNode in a text editor, and remove the Item section for that ability. There are plenty of deprecated abilities that I probably should have included. Like how Build Menu has 4 older versions when you should probably just use the newest. XNode All Abilities 2013.zip

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.