Tomi Maila Posted June 3, 2008 Report Share Posted June 3, 2008 I've just posted an article Extending LabVIEW-built applications with LVOOP plugins with an example project to ExpressionFlow blog. There are numerous reasons why you would like to allow your LabVIEW application to be extended with plugins. First you may want to allow your customer or a third party to add some new functionality to your application. LVOOP plugins provide a way for you to allow third parties to extend your application. Second you may want to separate the built and development process of the core application from the development process of the features of the applications. With OOP projects LabVIEW development environment slows down dramatically as the number of classes gets too high. It may be wise to separate your application so that only the core elements form the main application and all other elements are provided as add-on components. Third you may want to control the memory footprint of your application and specify at runtime which components are loaded into memory; there is no need to keep the code for unused features in memory. Consider for example that your application supports multiple file formats or device drivers. You can load the needed file format plugins or device drivers on demand into memory at runtime.Read more... Quote Link to comment
Tomi Maila Posted December 8, 2008 Author Report Share Posted December 8, 2008 I copy my comment to Pierre Cottin from the blog post to this thread as it may be relevant to the forum readers as well. PierreCottin Said: Very interesting article! I have tried to extend this example to a class Circle inheriting from a class Ellipse. I did not manage to compile the circle plugin to acces both circle and ellipse object. If I do not include the Ellipse class in the projet, it appears as a dependency but the source distribution does not include it. If I include the Ellipse class in the projet, I have to exclude overridden methods and send it to the support directory (to hide it from the main). With two methods, it's not so bad but with a real class hierarchy with several parents, it will be quite complicated. Do you know an easier way to proceed? Thanks. Pierre Hi Pierre, Which version of LabVIEW are you using? I'm testing the scenario you suggested with LabVIEW 8.6 and I have no problems. For the Circle plugin, I set both Circle and Ellipse classes as Always Included and voilĂ , everything works as suggested. I think the the previous versions of the builder may have had problems with colliding classes, so if you are using LV earlier than 8.6, you should consider upgrading. The plugin search algorithm I suggested in the example is pretty plain simple and you should not use this simple version of the plugin search algorithm with your scenario as it will identify all classes used by the plugin class as plugins themselves. Some other indication such as a setting file is needed for identifying the main plugin class. I created a modified example for LabVIEW 8.6 that demonstrates the usage of plugin inheritance. It can be downloaded from the same download page as the basic example. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.