Re : Packed Project Libraries

[Sipic]

I'm building a deployable application that dynamically calls a number of modules uring runtime.  To do this I'm aware that my dynamically called modules must be contained in either a packed library or in a subfolder that has the same relative path on the target as the development system.

I've put the dynamically called modules in a library located in the root folder of the project and built my packed library from it.  I have a switch in the application so that when the application is running in development mode it uses the packed library file as the root path and on the development system it uses the application folder as the root path.  The application runs fine on the development system but when it runs on the taget system the dynamic calls fail.

What I've found is that the VI modules stored in the packed library have their original literal file paths attached to them and so the relative path I pass to the asynchronous call I'm making fails to find the correct VI.  The work around that I'm looking for is to strip the paths off the VIs stored in the packed library but I've not idea if this is the right approach or if its possible.

I should add that this is the first time I've used libraries so feel free to correct any glaring errors.  I've attached a jpg of the project structure as it is.

Any suggestions out there please?

[Vincent90]

Hello Sipic,

What it the error you get in Run-Time ?

Did you try to split your functionnalities in different projects ?

I will create a new project HSTR Lib, Make it a Packed library.

Then call in your main project (STR i guess) this PPL.

BR,

Vincent

[Sipic]

Hi Vincent, thank you for responding.

I get a pretty standard error 7 File Path error and it took me a while to figure out what was happening as the library path is correct.  It's the sub-vi that has the extra path nformation.

I haven't turned the modules folder into a seperate project as the VIs are inextricable linked to the main project .  They derive all of their controls and common VIs from the main project.  The only reason I'm using a library is to permit the use of dynamic calls across platforms.  

I 'could' with a bit of effort further subdivide the main project into sub-projects but this seems like an extreme overhead for what I want to do.

[Vincent90]

Did your curent architecture works once already ?

BR,

Vincent

[Sipic]

It did Vincent.  

In the last release I put the HSTR Module folder in the build subfolder and created an installer that way.  Not in any way elegant but it worked.  I've since created the library folder in the development structure and a packed library in the build folder.  It's at this point my problems started.

[Vincent90]

Did you include the packed library into your installer -not the library-?

[Sipic]

Yes Vincent, I created the packed library first and put the build in as one of the source files in my installer.  The library is present on the target system after the installation.  I verified the cause of the problem by creating a path constant to the VI that I couldn't call and that's where I saw that the VI in the packed library has it's original path appended to the VI name

Many thanks for the help.

Simon

[Vincent90]

Glad it helps !

Vincent

[Sipic]

V frustrating this Vincent.  Problem is still there.  

The packed library is present but the path to each sub-vi is same path as the file on the development system except without the root drive letter.  The key thing for me is....how do I store the VI in the packed library without a path attached to it?

[Vincent90 · Accepted solution]

You could use this VI attached to get your application path.

Hope this helps.

Vincent