Reference Design Content
Application configuration is a large task for application architecture. In an attempt to make system configuration easier for designers as well as end-users, configuration editors are often implemented. In this document we cover the Configuration Editor Framework which is a starting point for creating a custom configuration editor in the LabVIEW Development Environment. The framework consists of a tree control and subpanel API, a LabVIEW project template, and 2 abstract LabVIEW classes.
Description
System Configuration is used to store and access semi-static data in an application which describes the hardware and behavior of the application. Configuration decouples the need to edit source code when a user needs to:
- make changes to parameters
- change hardware specific information
- configure application specific behavior
- customize applications for a specific use
The data for a configuration is stored in a file or database. At run-time, applications open the data from a file or database, rather than having the developer hard code the information into the source. Time and money is saved by removing the need to validate new source code. When editing configuration the user can work directly on the file with a text editor, excel or other file editing programs. General purpose file editors can work for simple applications, but forcing users to use these non-specific tools makes configuration hard to understand and error prone. Configuration editors are typically graphical user interfaces (GUIs) that enable a user to create/edit configurations so that the resulting file conforms to a format that an application can interpret. By enabling and limiting the interactions of data in a configuration the user can create a scalable and maintainable way to store information. Using a configuration editor provides several advantages:
- Information can be input in different ways
- Invalid configurations can be restricted by the configuration UI
- Decoupling the programmatic requirements from application requirements, makes it easier for users to visualize a complex system
- Version managing can be done by the Configuration Editor
- Multiple file formats can be supported
- Easier to configure complex system with large number of configuration parameters.
Additional Documentation
Compatibility and Requirements
- LabVIEW 2013 Development Environment or later
Dependencies
- Asynchronous Message Communication (AMC) Reference Library
Download
CEF on the LV Tools Network (requires VIPM client)
Alternative Download: If you require a direct download, you can access the VIP file from our FTP directory. We recommend the VIP file with the highest version number or most recently modified date.
Support and Feedback
Please submit your feedback in the Configuration Editor discussion forum so that we can improve this component for future applications.
Christain,
While reading this I was thinking about the counterpart of the "Configuration Data" but couldn't catch the exact terminology for the counterpart. Programatic parameter vs. Application parameter (where configuration data is more about application parameter) gives little sense. Configuration parameters are something which deals with the system setup data which once setup will not change very frequently whereas the other counterpart (maybe named as programatic parameter) is the one which will change very frequently. Is that correct? Correct me if I'm wrong.
Thanks,
Ajay.
Ajay,
That sounds correct. Configuration data is mostly static and set either before the application starts using a configuration editor or may be changed very infrequently from within a running application using something like an options dialog (e.g. Options Dialog Framework). Values that change while the application is running are often called variables. In other application spaces these may be called tags or state parameters. Unfortunately there is not just one term that is used consistently across different contexts.
In LabVIEW values that change frequently are either part of the application logic and stored in wires (dataflow) or may be stored in an asynchronous mechanism such as a global variable that can be easily accessed from application logic in different components of your application. The Current Value Table reference design is intended as one option that provides a flexible implementation for such dynamic data (tag) storage. It is part of the larger machine control reference design.
CEF is well designed and I believe this would be standard architecture to develop editor feature.
This is my demo application but didn't take a lot of time. I could easily develop it.
Im creating development manual now, is there someone who is interested in?
@Emboar
I'm trying to understand how have you done the disable option.
I'm guessing that you had to modify framework file (NodeMenuOptions.ctl)?
If so, is it correct? I mean I guess you have made what you probably expected, but I'm not used to change standard framework files.
@Johnny, Im creating CEF development manual but the progress is not good because I don't have enough time. Im sorry...
To implement disable option, I recommend you to override
A. NISE_CEF_serializable node.lvclass
B. NISE_CEF_serializable configuraiton.lvclass
Add "state" Boolean into child class of B and override "validate.vi".
In validate.vi, return an error if "state" is false.
Just take this step, you can implement "disable option".
Where can you change the Boolean state? Of course, in child of A.
I added "Enable" or "Disable" menu in "ShortcutMenu.vi". Which would appear is based on Boolean value.
Then, I edited "MenuHandler.vi" like below.
Emboar thanks for your answer!
Got one more little questions regarding your app.
Did you get the "view node data" and "attempt repair working"? I can see it on your .gif, but I wonder if it's actually working. #
That's where I'm struggling:
My MenuHandler.vi child is not being executed (NISE_CEF_serializable_node.lvclass)
I know I'm not sending the message to child and that's why it's not being executed, but I'm not sure where I've done the mistake.. hmm
So it ends with a fault:
Johnny, please move this discussion to https://forums.ni.com/t5/Development-and-Deployment/Configuration-Editor-Framework-CEF/td-p/2730619/...
Emboar, I've managed to get it working. The main difference is that you've based your project on Hierarichal template, where I've based it on Configuration Editor Project.
I do like the tools window though, so I will try to make something simmilar on the herarichal one. Once I complete it I will send some comments about it.
Also, I've managed to get the disable/enable working.. but not quite as I would expect and I think the biggest problem lays down in this VI:
What is it actualy? Where did you get yours?
CEF is well designed and provides good framework solution. "CEF" doesn't have a compatibility with LabVIEW NXG
but after you learned a theory of CEF, you can develop your original CEF application!!
