Can you elaborate on your diagram comment for the need of two FOR loops. Since your are indexing over the same array, shouldn't the iterations always match?
Argh! Thanks Altenbach. That was a modified older file. It "works" so I didn't think twice after I ran it then decided to post it. There were a few things missing in the old one as well.
Let's try again....
Here's a more complete list which was generated using a private method. It looks like there are ~280 classes in total and about 140 of those are BD classes. The BD classes seem to occupy the upper bit of an I16.
What I was trying to provide was a way to view the ClassID, the ClassName, and a picture of the item in question. Below is a representation of what I was trying to achieve by placing the items directly on the BD.
There are some surprises in there.... Is it intuitive that "GenClassTagRefConstant" is the ClassName for for the System Host?
Why is an Expression node just "Node"?
Decimate 1D Array = "Bundler"
Array To Cluster = "ArrayToCluster" but...Cluster To Array = ""Function"
Nice. You're probably better off using Traverse for GObjects though, which will recurse into any structures.
Also, there are some Class IDs which can have multiple Class Names - for example, all the Express Nodes and XNodes have the same ID but different names (at the moment, your list of Names and IDs might not be the same length, or match up properly).
I see the question of stopping multiple loops posted a lot. Here is the most recent example - stop button do not work.
This micro nugget has the following goals:
The assumption of this micro nugget is that the behavior of an uninitialized shift register is understood. I will not attempt to outdo Ben on his Community Nugget. If a novice LabVIEW user is getting to the point to where he or she needs multiple loops, this is a good time to learn about the concepts presented.
There are a lot of methods to signal loop shutdown and this is probably not the best. But it is probably the most simple acceptable way. It uses a Boolean Functional Global Variable. It also demonstrates how I like to privately scope FGVs in a library with public wrappers for the API.
Privately scoped items can only be used by other items in the library. In this example the FGV is only available to the wrapper functions which are Publicly scoped. You can modify the private items any way you want. After testing the public API you can redeploy the library and your applications that use it will work. If the applications directly use the FGV they would break if you modify it or remove it.
To change access scope you right click on a library item and select Access Scope. There are three - Public, Private and Community. Community scope will not be discussed here.
In a real application I would probably use a shutdown message with a notifier or queue instead. But I wanted to demonstrate this particular technique. I also want you to understand that since the FGV is private it could be removed and replaced with a notifier or other technique without breaking the applications which use the library. You can modify the inner workings of the API but the inputs and outputs stay the same.
I always call any privately scoped FGV or Action Engine "core.vi". The actions for this one are:
I always set the command enum to input required. Here is the Global Stop core.vi
I created three wrapper VIs - one for each action. I do this for several reasons.
Here are the three wrappers.
I have a test VI to demonstrate the use of this library.
Attached is a project containing the Test Global Stop VI and the Global Stop library along with the two SubVIs in LabVIEW 8.2 format.
I really like this approach Steve - wrapping the FGV's. Moreover, there's no errors to handle, such as when using Notifier or Queue errors to stop loops, like I
A really simple one, that I'd probably have known if I'd read the manual...
Adding two numeric clusters (e.g. position of a control) sums the corresponding elements, no need to separate them out and rebundle:
I'll pay credit to Darin.K for this - used in his angry bird game (which I've only just looked into after downloading an eval version of 2010... hmm, I'm cleary behind the times in more ways that one as it sounds like 2011 is here!)
I discovered recently that when working with a cluster on the front panel, if you group multiple elements they will stay together when the cluster is autosized. This means if you have, say, a cluster of 6 numeric values and you want it arranged in rows of 3, you can autosize the cluster for horizontal alignment, select 3 elements at a time and group them together, then autosize the cluster for vertical alignment.
Re: Steve's Micro-Nugget
I really like this micro-Nugget and would like to add another benefit to the list.
When we develop our Action Engine we may not the only user of the AE and are faced with the chalenge of try to ensure our AEs are being used correctly to;
1) reduce frustration for the users of our AEs
2) make it clear when they have been used inappropriately
3) and avoid those cries from the Bull-pen that would start with phrases like "Ben, your AE did ...!"
By creating wrappers for our AE we (the developer and most knowlegable re: the AE's inner working) can ensure the AEs are being used correctly.
As shown above my GUI Controller Core is initialized inside a wrapper. Since the GUI Controller may not be used until latter in the code, a failure to properly define the control references COULD result in an error far down the road.
Knowing this I include logic in the "Init" action wrapper to check to ensure the refs are defined before I proceed.
This little bit of "extra" has saved me time on multiple occasions when I added anothe control and forgot to why the ref.
Thank you very much for reading and...
THANK YOU STEVE for the Micro-Nugget!