Same vi, different behavior based on build spec?

[david_jenkinson]

Hi,
I have a vi which I plan to distribute, to two different classes of users.  Some of these users will only use a subset of functionality of this vi.  So I am wondering what the best way is of distributing the save vi, but with different behavior, so I don't need to maintain two top level vis.  I basically just want to hide a few indicators, and case around some code for a certain class of user.  My ideal scenario would be just to have two different build specs in my project, which I'd distribute the output of to each type of user.  My first thought was to have a command line argument, and use the labview capability to read command line arguments from the application property when the user launches the exe, so that each build spec would include a different shortcut with their respective command line arguments.  But when creating the build spec to automatically install the correct "shortcut" with the command line option, I see the "installer" build spec doesn't really let you specify command line arguments under the "shortcuts" section, just the path to the generated .exe, nothing more. 
Then I began investigating the "conditional disable" structure, and I see where you can add cases in the project properties, but how do you control the conditions variables in the build spec?  Do I manually change the value of the condition before each build?

Are there any other methods which are preferrable, and/or am I overlooking something in the two methods above by which I can make this work?  Or is this even possible?

I appreciate any help

Thanks
David Jenkinson

[Jason_P]

Have you considered using ini files?  LabVIEW's built in functions make these easy to manipulate...  You could make two different versions of the ini file, each one included in a different build spec.  Your app could check the ini at startup to determine which indicators to show.  Better still, if your user needs more functionality, it's very easy to edit an ini in the field.

Jason

[chrisger]

Hi there

Try this:

1. Pack the switches for the two distributions in a single VI (e.g. a boolean constant). Create to versions of the VI, one with switch == TRUE and one with switch == FALSE

2. Take a look at the example shipped with LV "..\LabVIEW 8.6\examples\project\programatically build\Build Targets Programmatically.vi". This VI builds a given build spec in a given project.

3. Replace the switch.vi inside the project path with version one of step1, run he build specification (step 2) and save the binaries to a different location

4. repeat step 3 for the second version of switch.vi

[david_jenkinson]

Ya I do see that there is generated an .ini file when generating the exe from the top level vi, I was just looking at that.  The default entries contained in it are:

server.app.propertiesEnabled=True
server.ole.enabled=True
server.tcp.serviceName="My Computer/VI Server"
server.vi.propertiesEnabled=True
WebServer.TcpAccess="c+*"
WebServer.ViAccess="+*"
DebugServerEnabled=False
DebugServerWaitOnLaunch=False

Do these proporty paths correspond to properties which labview can programmatically access?  I imagine if I added one to the end, say "ViewerOnly=True", is there an ini function somewhere in labview which will read this file, and look for a boolean control in my code labeled "ViewerOnly" and manipulate it?  Or would I need to code my own parser to do this?

Thanks

Dave

[billko]

---

david_jenkinson wrote:

Ya I do see that there is generated an .ini file when generating the exe from the top level vi, I was just looking at that.  The default entries contained in it are:

server.app.propertiesEnabled=True
server.ole.enabled=True
server.tcp.serviceName="My Computer/VI Server"
server.vi.propertiesEnabled=True
WebServer.TcpAccess="c+*"
WebServer.ViAccess="+*"
DebugServerEnabled=False
DebugServerWaitOnLaunch=False

Do these proporty paths correspond to properties which labview can programmatically access?  I imagine if I added one to the end, say "ViewerOnly=True", is there an ini function somewhere in labview which will read this file, and look for a boolean control in my code labeled "ViewerOnly" and manipulate it?  Or would I need to code my own parser to do this?

Thanks

Dave

---

I think what Jason P was talking about is creating your own .ini file where you could control which user sees what.  Maybe a key like:

user = x where x represents a type of user, or for readability maybe use a string instead: user = "Admin"

Bill

[david_jenkinson]

I see.  Ya that would definitely be a way to do it.  I guess I was hoping there would be an established "built-in" way, but coding my own wouldn't be too difficult.  If NI only included the ability to include command line arguments in shortcuts when building the installer, that would pretty much do it, because I can get at the command line argurments using the applications property in code, and could then just have a few case structures.  Would be kind of a cool way to do it.  Perhaps in some future revision.

Thanks

David J.

[Mark_Yedinak]

Have you considered using LVOOP? You could create different classes for distributions and use dynamic dispatch to invoke the correct method. Using this approach would allow you to be able to add new variations with modifying your distributed code. In addition you could upgrade a deployed user simply by replacing the object on their distribution.

[david_jenkinson]

Hmm no I had not considered that, but I will.  I have never played around with OOP in labview, or any other language, but have read about it.  I have a birds eye view of the concept, about objects and instances of objects, I will need to dive deeper to understand and apply.  But this may be the time to do that.  Are there any sources/examples you would recommend for becoming familiar with LVOOP?

Thanks

David J.

[Mark_Yedinak]

Here are a couple of things you can look at: Design patterns in LVOOP and LVOOP plugins. At the moment I don't have an example that I can point you at.

[Jason_P]

If you are somewhat familiar with OOP and want to learn LVOOP, I'd start with this:

http://zone.ni.com/devzone/cda/tut/p/id/3574

Then I'd go through the included help examples, especially the one that deals with dynamic dispatch.  That, plus lurking here and on LAVA was all I needed to get started.  There's plenty of stuff out there, and it is worth learning.  Having said that, it really seems like overkill for the problem you are facing.  My guess is that you could spend several hours trying to learn enough LVOOP to make it work, or less than an hour making an ini file that does the same thing.  The ini isn't as extendable, but the problem you are trying to solve sounds like it is pretty well defined as is and won't be changing much...

-just my 2 cents,

Jason