Leaderboard

In general, Darren and I add comments to our diagrams when, during a buddy session, we actually have to explain what's going on to the other. That's our standard measure for when a comment is needed. If the buddy session proceeds without the other person getting lost as we walk through, then the code and the API documentation (i.e. the Context Help) likely suffices as it is. My instinct in this case would be to put a Diagram Disable structure down and put the other version that I had tried in the Disabled frame -- then I don't have to describe what I tried, people can look at it. Now, that is only true when the other version of the code is all prims or vi.lib VIs, things that don't cause my source code to have additional dependencies when distributing it. As much as possible, I would still prefer to include the graphical "here's what I tried" and avoid a text description of it. It is both more accurate to say "I tried this" and if someone else says, "But that other way really should, by rights, be faster..." they can benchmark it themselves easily and/or spot any errors I had in my implementation. And if the compiler takes advances, it's easy to flip in the other code.Now, having said all of that, I do tend to include "proof of correctness" comments with complex algorithms, along the lines of "This loop works because earlier in this VI we already guaranteed that there are no duplicates in the array". This is especially true when I'm relying on a less-than-obvious fact of one of the upstream functions. For example, I recently wrote a VI with the comment "This works because the Controls[ ] property of a Front Panel refnum guarantees that the controls are returned in tab order." Most people analyzing my code for correctness wouldn't know that fact, even if it was properly documented (it will be in LV 2012), so it was worthy, IMHO, of a comment.

Hmmm. It seems you have picked a rather "special" action engine to demonstrate. I'd even go so far as to saying it's not one at all. Perhaps if you could put it in context with something simple (I like simple) and I'm more familiar with (e.g a list) I might be able to see the benefit. A list will have things like Add, Remove, Insert, Get Value etc. At it's heart will be an array of something. It will basically wrap the array functions so that you have the operations exposed from a single VI. There are two inputs (a value to do the operation on and an index if required for the operation) and one output. With this AE, how is the DVR method more robust, simpler, less coding et al? Here she is.

My post above was relating to dynamic in the sense of lazy loading. The Static VI Reference approach will load the VI into memory when the called VI is loaded. So it really depends on what the OP is trying to achieve. Using the CBR and specifying a path with an appropriate setting may work? I have not used this method myself. I checked and the VI Hierarchy Window shows the called VI when the caller VI is only open (I would have thought it wouldn't?). Cheers -JG <edited>

Here are the VIs we use for Windows authentication and domain groups. Validate Username and Password.vi takes the username and password and returns a TRUE if it validates against the domain controller. User in Group.vi takes a username (or current user if left blank) and a Domain Group name and returns TRUE if the user is a member. User Groups.vi takes a username (or current user if left blank) and returns an array of Domain Groups to which the user belongs. We only use these on our internal network, so I can't guarantee they work in every situation. Still, they may give you a starting point if you need something similar. Pat P.S. LabVIEW 2010sp1 User Groups.vi User in Group.vi Validate Username and Password.vi