Application builder - Best practice multiple applications from the same main VI

[Tonybj]

Hello!

I need to have two different applications (executables) based on the same VI but with minor changes (one control should be set to a value and made invisible). This is to have one application made for users and one application for the admin.

I use the build specification in the project view and have made some customisations but I have not found the possibility to change controls in the main VI.

How it is solved today:

- Manual changes in the block diagram between compiling the different versions via the build specifications. This can easily cause problems..

How I think it can be solved but seems.. wrong:

- Have two different "wrapper-VI's" that contains the differences and loads the main VI as a sub-vi and have the subVI be set to show its front panel. What I dont like about this solution is having the empty wrapper GUI be visible as its own window.

 Is there a best practice or suggestions for having build specifications for two almost identical applications?

[GerdW]

Hi Tony,

This is to have one application made for users and one application for the admin.

Why not use the "usual" approach to have just one application - with an "admin" login, which enables that control after successfully verifying the admin using its password?

[k-waris]

If you are looking two different executables one with control and second with fixed value then you can achieve this as follows:

1) Duplicate vi

2) Call first Admin Control and second Operator Control

3) In the second one, open block diagram and change control to constant. Enter desired value within constant. This will also disappear control on front panel for operator screen

4) Now use Application builder to create two executables- Admin Control.exe and Operator Control.exe

However, much easier way is to either leave as one executable and design a wrapper vi - call it Access Control. Use Enum control for values of 'Engineer' or 'Operator' Access. Make users enter a 'Password' if Engineer is selected. If password is correct you launch your vi with the 'Control'. When logged in as operator, control is hidden. 

Hope above helps..

[Nathan-M]

There's also the pre and post build VIs that you can run to programatically change the control/indicator properties. 

[Tonybj]

---

@GerdW wrote:

Hi Tony,

This is to have one application made for users and one application for the admin.

Why not use the "usual" approach to have just one application - with an "admin" login, which enables that control after successfully verifying the admin using its password?

---

That would be possible but would add more complexity in code, documentation and workflow due to communicating passwords to users, protection against bruteforce etc. I want ownership of the application to be the authentication.

I think I made a bad explanation calling them "user" and "admin", instead they are two different programs that shares 95% of the functionality.

So in retrospect the question is more broad, like "How do I branch an application into two in a way that is maintainable". Perhaps I was fooled by the similarity to keep them in the same application? I avoided breaking them up into two applications since then it would be two applications to maintain and changes in one of the applications could cause the other application to stop working (since they share classes).

[Nathan-M]

We accomplish something similar with a config file. Then each build spec has a different config file that it ships with, enabling or disabling certain features/modes. 

[Tonybj]

---

@Nathan-M wrote:

There's also the pre and post build VIs that you can run to programatically change the control/indicator properties. 

---

This is very interesting and is exactly what I would like to do based on my current understanding but I did not know that this is possible.

How can I make a VI change the source code (I guess properties are part of source code) of another VI?

I guess I could make a wrapper "pre.vi" that wraps the "main.vi" and sets terminal inputs, would the affected controls keep that value as the default value when built into an application?

[Nathan-M · Accepted solution]

You can use VI Server to get references to all the controls and indicators from another VI, then filter by the Control/Indicator label. From there you can just use the property nodes to make the necessary modifications. 

[Mark_Yedinak]

You could also use a single VI and two build specs, each creating a different application name. Modify the code to checks it's application name and vary the behaviour accordingly. This keeps all code in the main VI and controls operation based on the name of the executable. The downside is that if someone changes the name of the executable this approach will break. It also allows a smart user to be able to run as the admin simply by changing the name of the executable.

I would either recommend the wrapper, which you can make look like a splash screen or actually implementing the user authentication. You can also set the properties of the wrapper VI to have a transparent front panel.

[Tonybj]

---

@Nathan-M wrote:

You can use VI Server to get references to all the controls and indicators from another VI, then filter by the Control/Indicator label. From there you can just use the property nodes to make the necessary modifications. 

---

Thanks for taking the time of making this example, this is exactly the kind of solution I was looking for. I tried it out and it works great. The downside is having to find the correct control among the "control reference"-array but its solvable.

I made a small example project consisting of two build specifications having the same main.vi but one of the builds gives an application that does not have a button (mode) and a superuser application that has access to the button and can switch a value that is shown.