Factory Pattern Executable Limitations

[lvb]

Just wondering how everyone is handling the factory pattern inside of executables?

Some Background

A "bug fix" in LabVIEW 2010 broke the ability to list files inside of an executable: 201140 — Extracting or Unzipping LabVIEW built applications using Winrar or Winzip

I use the "Recursive File List.vi" to obtain a list of children for a class and populate ring controls:

This VI no longer works in a LabVIEW 2010+ executable. The proposed "work-around" has been to manually generate a string constant with the contents of the executable.

Work-Around

The best work-around seems to be the following: (which I don't like because of the manual Build Specifications step)

• In the snippet above, check if the environment is run-time or development
  
  • Development -> Call Recursive File List.vi
    
  • Run-Time -> Call EXE Recursive File List.vi
    

  [*]Use scripting in a Pre-Build Action VI to generate the Call EXE Recursive File List.vi

  [*]Remember to add the Pre-Build Action VI to every new build created

So...

• How are the LAVA members working around this issue?
  
• Is it possible to list files contained, but not loaded inside of an executable?
  

Looking forward to your comments...

[PaulL]

I am hoping you can clarify the end goal of this task a bit better. I think you are trying to get a list of suitable objects in the step you show. Later you will load an object of the type the user selects, in a sort of factory (not shown)? So this is an effort to use a plug-in architecture? Or am I missing this entirely?

Here are a couple ideas:

1) I show in the paper linked in this thread (http://lavag.org/topic/14213-strategy-pattern-example/page__fromsearch__1) how we use the Factory Method Pattern.

2) Another trick we use to determine a directory at run-time is to create a determinePath method on an object we do load. This method calls the "Current VI's Path" function (and then we can use relative paths from there).

Paul

[lvb]

I am hoping you can clarify the end goal of this task a bit better. I think you are trying to get a list of suitable objects in the step you show. Later you will load an object of the type the user selects, in a sort of factory (not shown)? So this is an effort to use a plug-in architecture? Or am I missing this entirely?

Paul

I am building a hardware abstraction layer (HAL) framework with hardware plugins. For now, the plugins will be contained within the LabVIEW executable. Using the framework in the development environment, a developer can drop their plugin class within the project folder and it will be detected using the above VI snippet.

For example, the HAL layer has a Power Supply.lvclass (interface). The developer places the "NI DC Power Supply.lvclass in the project (which inherits from the Power Supply.lvlcass). The application settings screen uses the VI snippet from above to search the project (or EXE) and populates a ComboBox or Ring Control with the available Power Supplies on the system.

• My goal is to list files (.lvclass) contained, but not loaded inside of an executable...
  

[Tim_S]

You're going to have to recompile to add them inside the executable; why not add the new object to a VI as well? You're other option would be to use a plugin structure.

[lvb]

You're going to have to recompile to add them inside the executable; why not add the new object to a VI as well? You're other option would be to use a plugin structure.

Adding the class constant to a VI would load that class into memory. In addition, I do not want the user to modify some of the framework. It would also be nice to simplify what is required of the framework user (i.e. eliminating the need to add a pre-build VI).

[asbo]

I take it you can't include the plugins themselves on disk as VIs (BD-stripped, if you like) and just build the plugin architecture into the executable?

[lvb]

I take it you can't include the plugins themselves on disk as VIs (BD-stripped, if you like) and just build the plugin architecture into the executable?

I would like to keep everything in an EXE. The goal is to make adding new "plugins" as simple as possible.

How are the LAVA members working around this issue?

It seems that a source distribution is the most common approach. Removing block diagrams is used for code protection.

Is it possible to list files contained, but not loaded inside of an executable?

It seems like the official way to do this now is using constants generated at build time as described in my first post.

• So there is no way to list items not in memory inside of an EXE in LabVIEW 2010+??? It would be nice if this was possible (at least with a VI that exists within the EXE)...
  

[PaulL]

Using the framework in the development environment, a developer can drop their plugin class within the project folder and it will be detected using the above VI snippet. ...

• My goal is to list files (.lvclass) contained, but not loaded inside of an executable...

OK, plug-ins, then.

See this thread (http://lavag.org/topic/14212-how-to-call-a-plug-in-object-from-an-executable/page__p__85567#entry85567), where I think we concluded the best options are source distributions (yuck!) or packed-project libraries using the method mike_nrao describes. (There is a link to the solution in that thread, post #9).

[lvb]

Paul_at_Lowell, on 09 February 2012 - 12:47 PM, said:

OK, plug-ins, then.

See this thread (http://lavag.org/top...5567#entry85567), where I think we concluded the best options are source distributions (yuck!) or packed-project libraries using the method mike_nrao describes. (There is a link to the solution in that thread, post #9).

Thanks for the advice Paul, I share the same sentiments with source distributions...

I am aware of the packed project library method from mike_nrao. I have been trying to avoid packed project libraries because I feel there are too many rough edges at this point. I just posted my concern regarding support in future versions of LabVIEW on the community page...

For now I will stick with my work-around of generating path constants at build time...

Edited February 10, 2012 by brianafischer