extract data from a subvi in a subpanel

[eskrut]

Hi,

I'm modifying a huge existing vi-program (300+ subvi). Among other things I want to change the main vi and the user interface. My main goal is to have a menu bar (listbox) to the left and sub-panel to the right where subvis are opened whenever the user change selection in the menu bar. This, I can do with invoke nodes.

The challenge for me (and for you - if you accept) is to save the changes done by the user so they reappear when the user re-select that particular point in the menu.

Secondly, I would like/need to extract the settings from the subvis (when the user makes another selection in the menu) to the main vi so I can use the settings in other subvis.

Thirdly, I would like the subvi, open in the subpanel, to be in run mode, for the interface to be interactive.

I have mange to make a draft-vi, but I fear that it will require too much computer power and memory when it has to be able to call 30 different subvis. I also feel that the data/setting extraction is a bit clumsy and could become quite messy when expanded. My solution to make the called subvi interactive is fairly simple, but I hope another solution could appear in the discussion.

FYI, the program has to be made executable at some point.

I really hope someone can bring my some inputs or comments to my draft-vi.

eskrut

[mikeporter · Accepted solution]

You have a very good idea. I have used it many times myself. But let's think things through a bit more:

1. You want to be able to pass data between plugin modules - which is a Good and Useful Thing.
2. When you get this running it would be another Good and Useful Thing to be able to reuse the architecture. Wheel reinventing is a Bad Thing.
3. If the user interface knows what the data look likes that is being passed between plugin VIs, it will limit your ability to fulfill Point #2.

So let's take things one small step further and say that the data passed between the plugins is private data that the plugins hide from the user interface (henceforth to be know as the reusable application framework).

In this scenario the reusable application framework has only one job: Opening plugins, starting them running and putting them in the subpanel. (ok so that's three things - nobody expects the Spanish Inquisition).

So how do you pass data? Functional globals, databases, events, notifiers, depending upon the details of what the plugins do, there are a bunch of alternatives.

Mike...

PS: The event for handling the selection should have all the code in it for managing the plugin. You can fire the event programatically during initialization to get things started. Likewise the list of options for selection can be populated programatically when the application starts.

PPS: Now that the reusable application framework has so little to do, give some thought to some other things it might have time to do - like providing a standardized error reporting mechanism; implementing a standardized menu structure that the plugins can hook into if they need to; or providing some common on-screen buttons that the plugins can use.

PPPS: Databases are a Very Good Thing.

[tst]

Try looking at this for inspiration:

http://lavag.org/files/file/204-jgcode-preferences-dialog-library/