Darren

Here's a VI that shows how to do the same thing, but with public properties/methods. Saved in LabVIEW 2012. Get Owning Project Name.vi

Argh! Force of habit giving that "VI Analyzer Tests" path, I guess. I've edited the post to refer to the "Quick Drop Plugins" location, and yes, you have to create it yourself.

Oops, I just double-checked in the code. The [LabVIEW Data]Quick Drop Plugins location for shared plugins is supported in LabVIEW 2010 and later. If you're in LabVIEW 2009, you have to put your plugin in the [LabVIEW 2009]resource location.

If you want a single plugin (saved in 2009) to be available in all installed LabVIEWs on your system (2009 and later), you can put the plugin VI here: [LabVIEW Data]Quick Drop Plugins

If you read the VI Name property of a subVI and it returns error 1099, then it's a missing subVI. At that point, you could read the Label.Text property of the subVI to get the name of the missing VI being referenced. To my knowledge, there is no way to retrieve the fully qualified name of a missing subVI.

I wrote this VI a while back for a colleague. It's not perfect, but it's the closest thing I've got. Saved in LabVIEW 8.6. Get Connector Pane Data Type Image.vi

There were changes made to the Icon Editor in LabVIEW 2012 to facilitate the addition of the LabVIEW Icon API. Thus, I don't suspect the shipping API in 2012 could be easily ported to past LabVIEW versions. Instead, you can check out the community version of the Icon Editor API here.

Yes, and unless I'm misunderstanding the question (and your clarification), the LabVIEW Icon API in LabVIEW 2012 allows you to programmatically retrieve and modify the text layer of the icon.

In LabVIEW 2012, we added a programmatic interface to the Icon Editor in vi.libLabVIEW Icon API. Among other things, this API allows you to modify the text layer of the icon.

If I need the *value* of the variant, and I know it's an arbitrary simple numeric type, I'll always just cast it to an EXT with Variant to Data and go on my way, because I don't really care what specific numeric type it is. But if I need the *type* of the variant, I'll use the VariantDataType VIs (located in vi.lib\Utility\VariantDataType) because they give me that handy type enum. Since I've long-established that dichotomy for about a decade now, I guess that's why I never thought to do the error cluster type check your way.

Hey, neat! Your way of determining if a data type is an error cluster... ...is quite a bit simpler than the way I do it: Sorry to get off-topic, but I always like to recognize cleverness when I see it. The only time your way would run into trouble is when the variant is a cluster containing a non-I32 numeric type: In this case, since Variant to Data will convert any simple numeric type into any other simple numeric type without error, your way would determine that the cluster was an error cluster, but my way would not. Incidentally, this code that I use for determining if a type is an error cluster is located here: vi.lib\addons\analyzer\_analyzerutils.llb\VIAnUtil Check Type If ErrClust.vi.

Hah, I just checked the link...the LabVIEW Wiki INI token is wrong. It's close, but it's wrong. I would tell you the right one, but since I work for NI, it's secret.

You may want to double-check that INI entry.

I don't think there's a particularly good reason why these are private. I have filed CAR 380592 and CAR 380593 to see about getting them changed to public in a future LabVIEW version.

Thanks for filing the CAR, Stephen...this thread fell off my radar. Yes, Stephen CARed the Delete From Array performance issue.

> ...I once needed to know if the output terminal of a compound arithmetic node was inverted, a small oversight in the scripting properties... For those that are curious, this scripting deficiency has been reported to R&D as CAR 197239, and is slated to be fixed in the next LabVIEW release.

I have no current plans to write such a wizard. But if the demand is there, we'll look into it further. A few weeks ago I created a new sample project for a colleague as a proof-of-concept, and it only took me a couple of minutes to construct the XML for it. Since I didn't need to customize the second page of the wizard, that's all I needed to do. Granted, I'm already familiar with the XML tags, so I understand it might take a bit more work for someone creating content for the first time. I do recognize, though, that creating a customized second page is non-trivial. Our working assumption so far has been that customizing the second page is not something people will be doing that often. If it turns out to be a much more common use case, then I agree we will probably need something more automated, or perhaps a more documented template, to start that process. The current approach is to read the webpage you mentioned, and use the Actor Framework's custom second page code as a starting point.

If you already have a project that you want to appear in the dialog, and you don't need to customize the second page of the wizard, then the XML is all you need, and you can start with one of the shipping XML files in [LabVIEW]\ProjectTemplates\MetaData and modify your copy with your project's specific information. If you do need to customize the second page, then yes, there is more work to be done, but you can start with the Actor Framework's customized second page code (referenced on that webpage) and modify it for your project.

Crap, it looks like it is. In my benchmarks in LabVIEW 2012, it looks like the Delete From Array "trick" is about 30 times slower than using Index Array. Oh well, I guess I won't use that trick anymore. Thankfully, Jarrod's Create Place VI Contents VI shortcut for Quick Drop made it really easy for me to add a shortcut to drop this code snippet instead:

Here's one I posted a while back that you just drop in any For Loop that may take a while. It will pop itself open and show progress if a certain amount of time has elapsed and the loop isn't halfway done yet. Darren's Weekly Nugget 06/26/2006

As you mention, it is in the online help for the function. We also try to indicate this behavior in the Context Help for Delete From Array: The fact that "last elem" is in parenthesis indicates that this is the behavior when you leave the index input unwired. If this isn't discoverable enough (which I'm thinking may be the case if people are writing VIs to do it), then how could we make it more obvious? I use this behavior of Delete From Array all the time...in fact, I may use Delete From Array just to get the last element of a 1D array more than I use it to delete stuff...

Traverse for GObjects.vi is available in Quick Drop/the palettes, so it's documented. It helps you find all the objects of a particular class within an arbitrarily nested panel, diagram, or object. As for finding a specific object with a specific label, there's a VI for that too, although it's not documented...check out <LabVIEW Dir>\vi.lib\Utility\traverseref.llb\TRef Find Object By Label.vi. This VI wraps Traverse for GObjects.vi with extra code to do the label matching. Let me know if y'all have any questions about either of these VIs (or any of the other goodies in traverseref.llb, for that matter).

The only way I was able to get the "strict" control references was to create a control reference control, right-click it and choose "Include Data Type", then create a constant from that strictly-typed control. In general, I only use "include data type" when I'm dealing with a control that can have different data types (like a listbox, which can be a scalar or an array), and I want to make sure that the VIs I have that may operate on the value of that control will only accept a strictly-typed reference. I should also point out that the easiest way to get a control reference control of the correct type is to drop a Control Reference from Quick Drop/the palettes, then drag a control into the control reference to define its type. I'm pretty sure that's how I created the control references for the QMH template.

Yeah, what he said.