Does the definition of "Execution State" equals "Bad" change between development environment and run-time?

[Taggart]

My basic question is:

If the execution state of vi is "bad" under the development environment, shouldn't it also be "bad" under the run-time environment?

So here is the background:

So I use SVN and I ran into this problem where I would be working on one piece of code without having my top-level vi open and would inadvertantly break the top-level vi.  And being in hurry or whatever I would not open the top-level vi to check the run arrow and I would check in my code, which of course breaks the top-level vi for everyone else and causes lots of problems. 

So to solve this I wanted to create a Tortoise SVN client side hook to check the check the top-level vi(s) to see if the run arrow was broken before I commit my changes.  I'm trying to use the Execution State to check this.  I am using an Equals primitive to compare it to a "Bad" constant. (as a side question is checking the execution state the best way to do this?  or is this even a valid way to do this?  It's the only way I've found so far to check the run arrow.).  

So the way I'm going about this is:

1.  I create a executable (written in LabVIEW) which is run by TSVN

2.  When TSVN calls it  (I set it up as a start-commit hook) I pass it a parameter which is text file which lists all the top level vi(s)

I do these first 2 steps in order to make it as generic as possible.  I can use it on any project with any number of top-level vis (or dynamically called vis) all I do is point it to a different text file.

3.  Inside the executable I just read the list of vis, open a reference to each one and check the execution state.  I do this inside a for loop, but keep the references open and close them after the for loop in case they share some subvis or libraries, so they stay in memory (could this be the cause of some of my problems??)

4.  Then after the for loop executes and the references are closed I simply fire off a popup if any of them are broken.

5. Then I simply exit LabVIEW to return control to TSVN.

So my problem is this:

In the development environment everything works as expected.  But when I try the exact  same thing in the executable it tells me the run arrow is broken.

Why the difference?  I'm checking the same list of vis and the runs arrows have not changed, they are still all good.

So it appears that checking the execution state to see if it is bad behaves differently in the run-time versus the development environment.

Can anyone confirm or deny that?

It seems to me that it should behave the same.

The help for the Vi.Exec.State property says that it works in the run-time (Read-only), so why am I getting different results?

On a side question if anyone knows of an easier way to accomplish what I want to do, please let me know. I went this route because I had some experience with writing TSVN hooks and I thought it would be pretty simple and it is if I can get this comparison to behave.

edited to fix a typo and to remove the duplicate attachment

[Mark_Yedinak]

The development environment and the application (run-time) environment have different search paths. I suspect that you are using an incorrect path when you try to load the VI which leads to your error.

[Taggart]

Thanks Mark!

I'll have to try that tomorrow and see if that solves my problem.  On a more practical note, how do you set the search path for the run-time engine? Is that in the .ini file?

[Taggart]

So yes Mark, that was the problem. I put a 0x10 for the options and sure enough a dialog box popped up asking to find some vis. 

Now 2 questions:

1.  Those vis were in <vilib>.  Why is that not included in the search path?

2.  How can I add that to the search path?  I looked in the ini file for my executable and that didn't have anything that looked promising.  Do set that in application property node or something?

thanks,

Sam

[FraggerFox]

http://zone.ni.com/reference/en-XX/help/371361E-01/lvhowto/adding_dir_vi_srch_path/

The above link explains answer for your second question.

For the first question, I believe that LabVIEW shall, by default, look inside the <user.lib> and <vi.lib> folders when it finds something is missing.

But just in case, you can also add this folder in your search directory option, as you can set LabVIEW to have multiple and hirerachial search locations.

[FraggerFox]

http://zone.ni.com/reference/en-XX/help/371361E-01/lvhowto/adding_dir_vi_srch_path/

The above link explains answer for your second question.

For the first question, I believe that LabVIEW shall, by default, look inside the <user.lib> and <vi.lib> folders when it finds something is missing.

But just in case, you can also add this folder in your search directory option, as you can set LabVIEW to have multiple and hirerachial search locations.

[Taggart]

Thanks for pointing that out!

I had found that.  I don't know if that will solve my problem.

My understanding of my problem is this:  I'm building an executable.  And it has references to some vis in vi.lib.  So when LabVIEW builds it, it includes those vi's in the executable.  Because you are building an executable it assumes that you want to be able to run it on another computer that doesn't have the dev environment so it includes them.  No problems there. 

The problem is that then I'm using that executable to open a reference to a completely seperate top level vi (specified dynamically), which also references items in vi.lib.  But now the executable does not know about vi.lib and its not in its search path, so it can't find them and now I have to search for every vi in vi.lib

I need to be able to change the search path of the run-time engine.  Anyone know how to do that?

[Mark_Yedinak]

You need to add all VIs you call dynamically to the "Always include" section in the application builder. Dynamically called VIs are not automatically added to your executable. They need to be explicitly added.

[Taggart]

I knew that you could do that, but I didn't think that you had to.

How do people develope expandable plugin-architectures then?  If someone would develop a new plugin, how does LabVIEW load the files?  Do they have to do another build to include those files?  I'm pretty sure I've seen demos of plugin architectures where you could build a new plugin and the exectuable would load it without rebuidling the executable.  (and I'm not talking OOP and dynamic dispatch - I'm talking straight vi server calls). If they can get that to work, then you must be able to get around including all dynamically called vi's somehow.

on a sidenote:  I went and added a  directory to the search path in the dev environment to see what it added to the LabVIEW.ini file and then I copied that into the ini file for the executable.  That did help some. It still took forever to find things, but at least it was looking in the right directory.  However it still tells me its broken, when if I open it up in the dev environment it isnt.

[Mark_Yedinak]

I believe that plugins rely on the libraries being located in a specific location. The installer can place these libraries in the specific location or some other installer can do that. You can create code that scans the library directly to "learn" what packages/libraries are available. Then you would build the path to that VI and open the reference to it.