hooovahh

So I understand the abuse side of things for sure, but anything can be abused right? If there is proper documentation, and training (which it sounds like there isn't) then I don't see anything wrong with this feature. Should every polymorphic VI not have the "Automatic" option when choosing the type based on the inputs? Should we have to be explicit about that as well? What about Data To Variant, should I have to tell it, hey this is a string and you should convert from string to Variant. I understand this example is weak given that it is a primitive and accepts all data types.

My vote is bug, but I've never seen this. Is it possible for you to post the VI? I'm curious to see if this works with other data types or somehow just is convinced a path is wired to the missing Type terminal. I guess theoretically this could be a feature, if all of the sink nodes are the same data type. But since NI hasn't done it yet I'm guessing it is a difficult feature to implement, but I would love to have a polymorphic VI change it's type based on an output that's needed, as well as its input.

Also check out this VI. <LabVIEW Dir>\vi.lib\Utility\traverseref.llb\Traverse for GObjects.vi

I'm in this same boat as well. I may want to bring my attention to something later, but I want the code to still be able to be ran. Using something like TODO: and searching for that string (or using the tool posted earlier) helps me see that something is important about the code, without having to break the VI.

I've only made a few XControls, so I might be missing some key aspect to get this to work properly...or it could be a bug, help me figure out which it is. I have a XControl that has the look as a System Combo Box, and functions very similar to one. It works just fine but I found that if I wrote to the control, using a property node, and the SubVI that the control is in isn't being shown, when I show the SubVI the control is blank, but the Value of the control is what I wrote to it. Attached is a SubVI that explains what I'm trying to say. Run the VI then set the two controls programatically using the buttons. Then you can read the values of these controls and see that the value you get is the same as you set. Then show the subVI. You'll see that the XControl doesn't have the value you set. Then with the SubVI window open set the XControl again, and you'll see the value change. This XControl is capable of handling a local variable, or property node value change write, because it works as expected when the UI is shown, but when the UI isn't seen, the control isn't right if I then show it later. Is this a limit or bug of an XControl? Thanks. EDIT: Saved in 2011 SP1, and the top level is Main Test.vi Double Edit: No one asked for a video demonstration but I figured why not: Video. XControl UI Update.zip

This is the way to go. The only issue to be aware of, is that you shouldn't generate an event in a subVI, for another parallel running subVI, until it has registered for the event. If you do generate the event before it is registered the event will be lost. You may want to implement some kind of hand shaking mechanism to ensure that a event is not fired, until it has been registered.

I think you've been hanging around hardware guys too much...or management...or sales.

Your example was with two string constants, so that's what I tested, which only had the two items you showed "Visible Items" (not labels), and "Properties". 2011 has "Properties" but not "Visible Items", so I was confused. I wasn't aware that this was a new feature that would work differently with other items on the front panel as well.

I completely agree, and I think you would be hard pressed to find someone who thinks this is the better way of doing things. I also wanted to mention that I didn't think this was a "new" feature. I think the only new thing NI added in 2012 was the visible labels. Just so others don't get confused, in 2011 I can select multiple items, and right click and I will get the properties option (I don't remember what version that was added). In 2012 they added the Visible Labels option. I did not think that NI had said that there were other new right click options in 2012, other than Visible Labels.

Yeah very useful for clusters of clusters of clusters...etc. I do my best to not have any items in my cluster have the same name as another item in another cluster. When hide long names is turned on, a quick glance may not be enough to ensure the right element was selected, if the same name is used.

Absolutely. The custom user events mechanism is very powerful when combined with a UI and I think it would be a great evolution to the QSM. Not used in all situations (someones signature comes to mind) but in my mind I don't know why I would use native queues anymore, other than possibly interfacing with other already written tools. And even then a wrapper could be done to convert an incoming queue to a user event.

There's alot of good discussion going on here and I don't want to introduce more topics, I just wanted to clarify what I meant. No what I meant was have a subVI that enqueues data, but just after it enqueues data onto the queue, it then generates a user event. The consumer loop is not polling anything, it has a while loop with a event structure with no timeout. But it does handle the custom user event. In the custom user event case it dequeues the data from the queue. I wouldn't go this route, but for those that like working with queues this would be a middle ground between user events and queues. I would take it a step further and not use a queue, but use a user event for consumer/producer data which means no polling, and all events (UI events or other) are all handled in one event structure, without polling. Hopefully with my clearer explanation you'd see that there would be no polling with #2, and no timeout. There are multiple receiving mechanisms, but one triggers the other, so in reality you are only waiting for one to fire, and when it does, go handle the other. Attached is a very quick test of method 1 and 2 I mentioned earlier (in 2011). Just open the main and run it. It will enqueue 5 things to handle, (500ms apart) and the consumer loop on top handles them one at a time and then waits for user interaction to hit the stop button (without polling). Again I would use method 1 which only uses user events, method 2 uses user events but queues as well. Queue Event Test.zip

I've thought of two possible solutions to this. 1) Only use User Events to pass data around and don't use queues. 2) Or have the queue fire a User Event, telling the event structure to go read a queue message. The obvious benefit from this is no polling. Your VI will sit idle until either a command comes in, or the UI event is fired. Of course if you need polling you can enable it by giving your event case a timeout. I've heard that behind the scenes a user events are just queues so I wouldn't expect much (if any) performance difference.

From MAX the File >> Import function worked as you described, where it will show you what things it will replace or change, and allow you to make adjustments. I was assuming that the import from the palette, or the import from installer wouldn't give you that option and would just import it without prompting you, but I've never used these two features. I just assumed they worked that way because I couldn't see an installer prompting for those kinds of settings. I also don't know how they would interact with the silent install switches that NI installers support. I agree, that at a minimum, the build specifications should indicate what things it will include, likely by checking their corresponding items in the Additional Installers section, and then allow you to uncheck things you know are already installed.

I have seen that option, and every time I go to use it I had issues of some kind so I just distributed the .nce file along with the installer and had to import it manually, which I think I prefer because you can then resolve conflicts manually where the auto import may not make the decision I would about which hardware is what alias. That being said I think it wouldn't be too difficult to do this your self, using the Import function on the palette, as you suggested as a Post-Install function that I believe you can do. I'm sure you can understand why NI decided to include so much extra content when you decide to create an installer with the nce file. What if MAX isn't installed when you run your installer? It won't be able to perform the import...but still 330MB! It probably includes a run time engine or two, (which are now over 100MB each), and then possibly DAQmx, maybe NI-VISA, and MAX so I can see why it would be that much. I almost feel like you could make 2 installers, one that installs MAX, DAQmx, VISA, and any other things you need (NI-DMM, Switch, NI-Power), and then have your second installer that is your 9MB program which imports your nce as a post install function. Then have the user install both if it is the first time new machine, or just run your smaller installer if it is an upgrade. That way when you push a new version of your code you will only have to deliver a new 9MB file, instead of a new 330MB file, with 321MB being the same as the last release.

Put me down as another member who would love to see this tool. You are welcome to do as you please, but why even post an image of this tool, if you are unable, or unwilling to share it?

Thanks, not sure why I didn't think of that.

I had a big long explanation typed up and accidentally it the back button. I don't fee like re-typing the whole thing so here's the shorter version. I have a reentrant VI that is launched multiple times. In development you can open a reference to the VI by full path, but in an EXE the path is unknown. So you open the VI reference by name, but for this to work the VI needs to be in memory. So attached is one technique I've seen to keep a VI in memory by putting it in a case that will never be executed. Just run the Main.vi click Make New Graph Window and stop when you are done. This code will work when built into an EXE because nothing is opened by path. Is this the right way, or are there other ways to force the compiler to add a VI as a dependency, so that a new reference can be opened by name? Reentrant Reference Test.zip

Whats the conversion from cookies to Internet points? To Internet dollars? To Zimbabwe dollars? Back to cookies?

Pretty interesting, which is why I told you about it. You posting it kinda feels like you are stealing my internet points. I'll just have to make some posts around here that don't add anything to the conversation to get my post count up.

I do want to load a VI silently, even when the VI is broken. I also want the load to take as little time as possible. Say I want to do this for 1000 VIs and each of them are broken for some reason. If I use 0x20 each VI will take about 20 seconds to load, for each VI it is missing. This is a guess of how long it takes LabVIEW to give up on trying to find a missing VI. However if I open it in LabVIEW as normal, I can just click Ignore All. I would like to have the same functionality as Ignore All, but programatically. AQs previously posted VI seemed to be just what I wanted but I only have 2011 installed, and it did not perform as expected.

I appreciate the suggestion but that is not a solution. The help has this to say: Hide loading dialog box—Prevents LabVIEW from displaying the loading dialog box when searching for missing subVIs of the referenced VI. Note This option flag does not affect whether LabVIEW prompts you to find the missing VIs or not So it sounds like if you use 0x20 LabVIEW will not show the loading dialog, but will still be searching for the missing VIs. I want to perform an Ignore All, meaning just skip missing VIs.

Old topic I know, but I tried using this VI in LabVIEW 2011 and it no longer works (at least for me it doesn't). Is there an update that will work? I realize this VI was developed before the "Ignore All" button existed in the loading window, but I'm looking to open a reference to a VI programatically. Is there a way to open a reference to a VI on disk, and have it perform the same function as if I pressed Ignore All? Thanks.

I know that each CAR and bug fix probably has a huge amount of information about it. Things like under what conditions it is reproducible, and what work arounds are available. But I can't help but think that NI could have been a little more descriptive with their one sentence summary of this bug fix. Also I thought it was odd that a patch was released for a version of LabVIEW which is not the latest, and by that I mean 2012 which was released a few weeks ago.

Wow very tool tool, not sure how I didn't see this sooner. One thing I wanted to bring to your attention that you may already be aware of. I found that some more complex data types cause the XControl to crash in a strange way causing me to have to kill LabVIEW. If the data type is an Array of Clusters, and in that cluster is an element that is an array, I will get the following error: This error mentions to Right Click to fix the issue. But at this point if you right click the control, this VI becomes un-responsive and cannot be closed. If you don't right click the control you can still control the VI and stop and close like normal. This was seen in 2011 SP1. Attached is the example VI I used which causes the error saved in 2011. Is it possible to accommodate these more complicated data types? Or possibly just detect these data types, and not attempt to read them into the XControl so that this dialog and lock up issue aren't seen? Thanks. Array Probe Test.vi