As promised, this time we are exploring using the Run method with subpanels. Attached is a simple application which has a plug–in architecture implemented with subpanels.
Start by getting the application running on your computer. Unzip the application to the directory of your choice, maintaining the directory structure. Correct the directory information in the two INI files in INIFiles subdirectory. Alternately, regenerate them using the VI in Tools subdirectory. Now run Main.vi in UsingSubPanels.lvproj. It is a simple app which switches between subtracting and adding two numbers. Stop it by clicking the Stop button.
Open the block diagram of Main.vi. The program architecture is a synchronous, event–driven task handler. This architecture was explained at the beginning of the Xylophone Project, so we will not repeat it here. Let's look at how the Run method is used with plug–ins and subpanels.
First, a series of user events are defined. These are used for communication from the plug–in VIs and the main VI. Notice that the DBLs are handled in the event structure of Main.vi. Evnt_Exit is used to stop the plug–ins, so is handled there. The local shift register in Main.vi is used to cache the plug–in object references, the user event references, and the current values of the inputs (kept up–to–date using the user events).
The Init case is the first case run. It first finds what plug–ins are available by looking in its directory for files with a certain filename pattern. This is one of a plethora of ways to find plug–ins. Some other options are registry entries (Windows only), a single file, binary file(s), or requiring the plug–ins to be in a certain directory. I like the multiple file approach since it lends itself to other people making plug–ins, and it does not limit them to putting those plug–ins in a single location. It is also cross platform. The front panel ring selector is populated with the results of the search.
Next, references to all the plug–in objects are created from the values read from the INI files. These values are cached in the shift register and the first one selected to initialize the subpanel. First, the VI reference is opened based on the plug–location. Then, the VI is run using the Run method. This prepares it for future use. The object keeps track of whether the VI is open or not and simply returns the value if it is already open.
The VI is then loaded with correct values. Notice that instead of using Set [xxx] methods on the controls, they are set using Value (signaling) properties. This is because the VI is already running. If a plug–in is loaded, it is kept running in memory until used again to speed load time.
Finally, the VI is inserted into the subpanel. The user sees a seamless interface that only changes its operand when the operand is changed. The function is changed, the reference to the new plug–in is created/fetched, the new plug–in is initialized, the old plug–in removed from the subpanel, and the new one inserted.
On exit, the running plug–in VIs are signaled to quit using the Evnt_Exit user event. All event references are then cleaned up by the main code.
This example uses user events exclusively for communication to and from the plug–in VIs. Other interprocess communication methods, such as queues, notifiers, and occurrences are also commonly used. The use will depend on the functionality and complexity of your code.
Subpanels are useful when you want to change the functionality of your code while keeping the GUI small. They lend themselves to the sort of plug–in architecture that is shown in this example. Try to create another function by copying one of the current ones. Be sure to make the object a child of the PlugInParent class. Function.vi is not in the class because it cannot be called and run dynamically if it is dynamically dispatched, but it cannot be overridden if it is not. Thus, the class and Function.vi were encapsulated into a library.
Have fun. Let me know if you have any questions.
Previous Installments
Message Edited by DFGray on 10-02-2009 03:57 PM
