Weird path problem with "nested" open VI

[hilbert00]

Dear all, 

   I'm facing a problem with path building in my application that heavily relies on Vi Server and I really appreciate your help. The situation is the following. I've a deamon VI (for simplicity let's call it deamon.vi). This is doing a few things and among the others is also loading on demand LabVIEW classes to implement plugins (plugin.lvclass). To do that I've a Get LV Class Default Value VI feeded with the proper class path. To build this path I'm using the Application Path constant that is properly pointing to the directory where the project file is located. It works fine.  

There is also a deamon launcher (deamon-launcher.vi) that is starting all the needed copies of the deamons and keeping an eye on their status. To start the deamons I'm using the Open VI Reference using the path to deamon.vi built with the Application Path that again is pointing to the project root folder.

For reference this is the project folder structure:

Project Root

--> Deamon Folder

     ---> deamon.vi

--> Plugin Folder

     ---> plugin.lvclass

--> Launcher

     ---> deamon-launcher.vi

myproject.lvproj

Here it comes the problem, as soon as the deamon will try to load the pluging classes, the Application Path will be pointing (for some not understood reasons) to the directory where the deamon.vi is located and NOT to the project root folder, that in my specific case, are not the same. 

Do you have any idea or suggestion? 

Thanks a lot for your help!

Toto

[mikeporter · Accepted solution]

I have no idea, this is not how it is supposed to work. Can you post a simple example that shows the effect? Or at least some screen shots of the paths that you are getting and when you are getting them?

Are you sure yo are opening the launcher VI from within the project's context?

Mike...

[hilbert00]

Thanks Mike! I'll try to put together a small example reproducing my problem and let you know ...

cheers 🙂

[Yamaeda]

Common problem. When building an application the vi's are "bundled into the .exe" so you'll get an extra level of folder.

Add a App.kind-property and if kind = Run-time, remove an extra folder when building the path.

There are several threads on the subject.

/Y

[hilbert00]

The problem is not with the built app!

But apparently Mike is right and the issue is somewhere else since this morning I've tried to replicate the misbehaviour on a oversimplied project and it is not there. 

I'll keep you updated!

cheers,

toto

[mikeporter]

If you build an app basing everything off the Application Directory and use the new exe structure, many of the problems we used to have with paths just go away.

Mike...

[hilbert00]

I got the answer! The solution was in Mike's sentence: 

Are you sure yo are opening the launcher VI from within the project's context?

The deamon launcher was erroneusly opening the deamon using the default application instance and not the project one. My fault 🙂

[hilbert00]

I got the answer! The solution was in Mike's sentence: 

Are you sure yo are opening the launcher VI from within the project's context?

The deamon launcher was erroneusly opening the deamon using the default application instance and not the project one. My fault 🙂

[gmazza]

Hi, 

sorry for the intruaion.

I have a problem with an append path from the "build path" function.

Built the path, it enter in "list folder" function but does not pass through the tunnel of the for loop.

Instead, if I wire a path controll to the "list folder", the path pass through the tunnel and the vi run as it should.

I attach the image of my VI so you understand better.

Please... Help me! 

[mikeporter]

I'm sorry I don't understand what your problem is. You should probibly start a new thread because it was only a matter of luck that I saw this.

Mike...

PS: If you don't feel completely comfortable in English, perhaps you could post your question in Italian. Google translate often does a pretty good job - even with technical stuff...