Best way to create one app with several sub-apps

[MartinMcD]

Hi everyone,

At the moment I've created a few different data acquisition apps for our company that get used by 20 or so people. We have one app for talking to rig A, one for logging from rig B etc etc.

I would like to create a more streamlined approach, my plan is this:

- The distributed app launches up and shows a 'what do you want to do' panel. (Talk to Rig A, B C etc).

- The user selects the one they want and then the relevant app is loaded into a sub panel within the launched parent, but it fills the panel.

I've run into trouble getting the sub-panel child vi to set the parent's run time menu and be notified of menu events etc. I dare say I'll figure this out if I keep plugging at it but it makes me think there must be a better/more elegant way.

I was wondering if anyone could suggest a better approach to this type of problem please?

Thanks,

Martin

[Marcus J]

Hi Martin,

With a reference to the TL-VI wired to the VIs that are loaded into the subpanel, you should be able to do what you are trying to do, for instance get a ref to the TL-VIs menu, and manipulate it.

But with just the information about the apps, it's hard to know if the sub-panel approach is recomendable.

Here are some random thoughts about some of the alternatives i see:

1. Independent apps with launcher
   This is simple, your apps do not share any GUI functions (not the old fashioned way at least) and have no natural common denominator or shared resources. You could build your apps as source distributions and the launcher could easily launch new apps you add to the suite.
2. Subpanels
   I'd use this if the apps have a limited set of behaviours, and more important, they have some common ground. Perhaps all the apps use different sets of hardware but the report is the same.
3. Kind of Object Oriented approach
   Regardless if you use subpanels or not, if your apps are somewhat alike, it could be good to try and sort out how they are constructed. Perhaps you could put all the common functionality of the TL-VI into a few VIs that use some kind of repository (perhaps an uninitialised shift register).
4. Straight Edge OO
   Using classes and inherritance you get some pretty good ways to handle this kind of a problem, but with legacy code it's more like shoulda-woulda-coulda

Hope you stopped reading before I messed it up completely.

If you didnt, and you are indeed messed up, you have my deepest apologies.

/Marcus

[Grampa_of_Oliva_n_Eden]

I gave up on the "Instantly infinately flexible" apps a while ago. Unless you can limit what the app will be doing, I never found a single GUI that would serve all needs.

So how about turning it inside out and make the TL, a launcher that once they select from the flavors they want to use, hides itself and is never seen again and all version related stuff is kept in the code that realizes each flavor.

Ben

[PaulL]

Martin,

One thing I have done successfully in a similar type of application is to use the Command Pattern. Ultimately I only need a single controller that receives messages on a single thread (I use a single shared variable), and the controller delegates the individual tasks to the appropriate model (which, in turn, the received command specifies).

Paul

[MartinMcD]

Thank you everyone, I'm now trying the bespoke tiny launcher idea that seems like a better approach, thanks.

I created a source distribution of a dummy app (displaying the increment value in a while loop until stop). I'm now trying to find out how to open the vi within the library - Open VI Reference is complaining that it is not a path. I've used MyLib.lvlib\count.vi and MyLib.lvlib:count.vi Any ideas please?

Thanks,

Martin

[MartinMcD]

Thank you everyone, I'm now trying the bespoke tiny launcher idea that seems like a better approach, thanks.

I created a source distribution of a dummy app (displaying the increment value in a while loop until stop). I'm now trying to find out how to open the vi within the library - Open VI Reference is complaining that it is not a path. I've used MyLib.lvlib\count.vi and MyLib.lvlib:count.vi Any ideas please?

Thanks,

Martin

Just reading up on this now - this may help anyone else thinking the same:

http://digital.ni.com/public.nsf/allkb/8545726A00272EB0862571DA005B896C

[MartinMcD]

Just reading up on this now - this may help anyone else thinking the same:

http://digital.ni.co...62571DA005B896C

Me again,

The Dynamic Load Example in the Example Finder works exactly like I want with the exception that I want to be able to open either ideally a vi from within an lvlib (which it seems I can't do) or call an exe. I've found one way of opening the exe using .net constructors and an invoke node which has the feeling of being the hard way of doing things & therefore probably wrong.

Can anyone advise please?

Thanks,

Martin

[MartinMcD]

Using this System Exec vi works but it brings up the command window which is a bit unsightly.

[jgcode]

The Dynamic Load Example in the Example Finder works exactly like I want with the exception that I want to be able to open either ideally a vi from within an lvlib (which it seems I can't do) or call an exe. I've found one way of opening the exe using .net constructors and an invoke node which has the feeling of being the hard way of doing things & therefore probably wrong.

Hi Martin - below are a few notes on dynamic process' and building executable that may be of interest.

One easy way to launch a dynamic process (whether it is a daemon or a GUI) is to have a launcher VI in the library that has a static reference to the process.

This will mean that the process is always included in the build.

Otherwise you must specific it under include dynamic VIs as part of the build spec for the executable (or it won't be included).

The other reason for doing this is that finding the VI is easy, you do not need to specify a path, as you already have a reference.

This is handy as in 2009 the way an executable's internal structure is composed is not like an llb (although there is an option to do that).

In the above png I don't have to worry about specifying a path, it is all taken care of by the static ref (the subVI just call the VI Run Method using the path as an input)

Additionally the front panel of a VI will get stripped in a build unless otherwise specified.

If your process is only a daemon (no Front Panel) this is ok, if it is a GUI then it is a problem.

One way to deal with this is to include a property node to a Front Panel control (even if it does nothing), that should guarantee FP inclusion in the build.

Additionally I am a big fan of the subpanel design where appropriate.

It does depend on screen-to-screen interactions.

Do no subpanel screens need to be opened at the same time (i.e. only one can be seen at any one time)?

Do all screens have common run-time-menu and/or tool bar options?

If yes then IMHO it can be a good candidate for a subpanel design.

All main screens are contained in the one top level screen - so I find this to be neat.

More work though, but it depends on the application.