Class plugins in LV binary application

[LAVA 1.0 Content]

We have a large application that uses plugins that third parties can write using LabVIEW development environment. We have both a native VI application alternative for users who have LabVIEW and binary application for users who don't. For both the native VI application and the binary application we need to have plugins that work exactly the same way in both environments and do the same thing. We have used VI folder plugins for the not binary builded LabVIEW application and builded .exe plugins for the binary application. Both plugins have been called using Open VI reference. This worked perfectly in LV 8.0 as VIs inside exe file can be opened using Open VI reference.

Now we are moving our application to LabVOOP. The intention was to create plugin classes or indeed we already have plugin classes. Each plugin would derive from a general plugin class. Each plugin would have a main VI which would just return an object of this general plugin class type. Due to the plugin nature this main VI needs to be opened using Open VI reference and then called using call by reference node.

Everything works in with native non-built plugins under LabVIEW development environment application but it seems that LabVIEW 8.20 cannot call the VI inside a binary plugin exe file any more. So our plugin system that worked perfectly for binary distributions under LV 8.0 application doesn't work under LV 8.20 any more. What would be an alternative. A DLL doesn't support returning classes as far as I understand so it is probably out of the question. We just need to be able to call a main VI that returns a plugin object and then use this object in our binary application in a environemnt that doesn't have LabVIEW development environment installed. Any ideas anybody?

[robijn]

Hmm you'respawning threads like labview spawns parallel processes... Should we first get more depth in the other ones ? I have some material left for the locking issue... No time right now though.

Joris

[LAVA 1.0 Content]

Hmm you'respawning threads like labview spawns parallel processes...

I just have a dataflow mind

. Seriously this is a real problem we need to solve now and not like all those high flying ideas I have thrown around.

[robijn]

I just have a dataflow mind

. Seriously this is a real problem we need to solve now and not like all those high flying ideas I have thrown around.

Do you think there's an obstacle for loading a .lvclass in LV10 ?

Joris

[Tim Erickson]

I responded to a similar question on the NI forum:

http://forums.ni.com/ni/board/message?boar...ssage.id=209642

[Jacemdom]

We have a large application that uses plugins that third parties can write using LabVIEW development environment. We have both a native VI application alternative for users who have LabVIEW and binary application for users who don't. For both the native VI application and the binary application we need to have plugins that work exactly the same way in both environments and do the same thing. We have used VI folder plugins for the not binary builded LabVIEW application and builded .exe plugins for the binary application. Both plugins have been called using Open VI reference. This worked perfectly in LV 8.0 as VIs inside exe file can be opened using Open VI reference.

Now we are moving our application to LabVOOP. The intention was to create plugin classes or indeed we already have plugin classes. Each plugin would derive from a general plugin class. Each plugin would have a main VI which would just return an object of this general plugin class type. Due to the plugin nature this main VI needs to be opened using Open VI reference and then called using call by reference node.

Everything works in with native non-built plugins under LabVIEW development environment application but it seems that LabVIEW 8.20 cannot call the VI inside a binary plugin exe file any more. So our plugin system that worked perfectly for binary distributions under LV 8.0 application doesn't work under LV 8.20 any more. What would be an alternative. A DLL doesn't support returning classes as far as I understand so it is probably out of the question. We just need to be able to call a main VI that returns a plugin object and then use this object in our binary application in a environemnt that doesn't have LabVIEW development environment installed. Any ideas anybody?

Why not use LLBs?