Leaderboard

I would oppose the general disemination of the "Get Name of Class.vi" without a lot of caveats. Specifically, I'd be tempted to name the VI "Get Name of Class in a highly inefficient but generic manner good for probes but inappropriate if you are really writing a by-name-lookup object hierarchy.vi" ;-) Here's the deal: This VI flattens your entire object data to a string. That's not cheap and it gets even more expensive as the object carries more data. If I am really writing a hierarchy where I expect to do name lookups -- like for database storage type systems -- as part of my actual runtime code, I'm going to add a dynamic dispatch method to the root class called "Get Class Name.vi" and override that at every level of the hierarchy to return a string constant. This avoids the memory allocation and performance hit of the flattening to the string (indeed, if all goes as planned, in 2013's compiler, it will avoid any memory alloc entirely as long as the returned strings really are constants). This solution is what is used in C++. Using any sort of reflection API to get this information in C# is less efficient than adding the "get class name" method. As far as I know, nothing beats adding this to your class definition. We don't do it for all classes generally because it extends the dispatch table with a feature that most classes do not need. The class-to-path function that is in the palettes today is mostly to support scripting and debugging type work. Can you find a way to address these concerns in the VI's icon, name and documentation? You must be using an old version of LabVIEW. They started working in RunTime in LV 2010. I would NOT recommend using them -- they are VERY slow, because they aren't meant to be used in production code (they instantiate entire projects behind the scenes because they assume you're getting one of these references in order to do manipulation of VIs into or out of libraries or to query about project layout stuff). They should be used for scripting and tools work, not for the actual work of your application. The only reason that they're in the runtime engine is someone wanted to be able to do reflection of projects from TestStand without needing the full development environment.A couple of renaming suggestions: "Is Default.vi" ---> "Is Default Value.vi" (just seems clearer to me and leaves namespace open for other "Is Default..." type VIs in the future) "Same or descendant class.vi" ---> "Is Same or Descendant Class.vi" (use of Is to be consistent with other VIs that primarily return a Boolean; also fixing capitalization to match others) "Fully Qualified Class Name.vi" ---> "Qualified Class Name.vi" (the Fully is redundant and the shorter name gets more useful info into the palette display) "Class Name.vi" ---> "Class File Name Without Extension.vi" (the class name is defined throughout LV as either the file name or the qualified name. This makes it clear what is being returned. Again, I wouldn't ship this VI myself, but if you do include it...) > Putting these VIs in LabVIEW Data would be fine, though that library is quite large already Can you add them to a subpalette of the "Cluster, Class & Variant" palette? I don't know what ability you have to add to the built-in palettes of LV, but that would seem to me to be the right place for them.

If you are going for using a version control system (VCS) as a deployment server I would advise Mercurial or Git (distributed VCS or DVCS). You would setup a deployment server that only the author of the tool has write access. The author would setup a development server for his hour-to-hour checkins/commits (Save early, save often). When a release is ready you'd push the changes to the deployment server.* On the end user's side the toolkit is installed with 'hg clone http://mercurial-deployment-rep'. Periodically, you can use 'hg incoming', if there are incoming changesets you'd use 'hg pull -u' so that the working copy (visible files) are updated. If you setup the deployment server as a HTTP-server you can also allow the server to have a zip/tar as a single download of the current state of the project (so the client doesn't need Mercurial installed). Now for user engagement a DVCS is particular practical, the end user would pick up bugs and improvements and save them. If they want them to be fixed on the deployment server, they would commit them to there local repo, and publish them somehow (via http, file) to the developer. The developer would look at the changes and accept them (or not). That is a superb way to have your users committed. Such services are provided by commercial hosters like Bitbucket of Github) Ton *If you don't want your users to know the history between the releases you could setup the rebase extension, that pushes the different changesets as a singel changeset.

The compiler can't realize this (because the control might be controlled externally, for instance by the Set Control Value method), which is why NI used this method (converting constants to controls) to maintain backward compatibility when you upgrade code from before this optimization was added to the compiler (which was LV 8.0, if memory serves).

The best way in my opinion is to obtain your CLD. Being able to do that means that you are a pretty good programmer. If that is not an option for you then you can look at the example material and checklists. Do the sample exams and post to the certifications board and ask for feedback.

I think it's possible in any version. I did a quick test and it looks like you should be able to call resource\Framework\Providers\VILibrary\LIBUIP_Properties_Dialog.vi with a reference to the new class then it will do exactly what you want. You just need to invoke Save after the dialog closes.