Jump to content

Extending LabVIEW-built applications with LVOOP plugins


Recommended Posts

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...

Link to comment
  • 6 months later...

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.