Get Project Items in executable

[LachlanITG]

I have no problem working with property nodes, i understand that if i have the reference already then I can use that to get the information i want, as stated previously I have done this already and it has worked. My specific problem is in getting a reference to the clusters without passing that reference in from somewhere else. I would like to build that reference from within my vi.

Open a reference to another VI, get the references to the controls in that VI, figure out whatever scheme gets you specifically the control you want, and pass that reference into the property node.

It is probably easier for you to just create an array of names that you fill out based on each VI if you have a difficult time working with property nodes.

---

I can get a static vi reference which would give me a way to get the information i need, however I do not want to statically assign anything to my vi as I am trying to write something which can be reused in any of my other projects.

[paul.r · Accepted solution]

If I am understanding correctly, you want your .exe to interface to development environment controls? Why not use file browser functions? (Call the 'Recursive File List.vi' with the pattern *.ctrl on your project directory) Then you can open the control references using the open VI reference node, I believe. 

Looking at your code, it actually looks like all of the properties you are using are supported in run time environment, aside from the 'find children' property of the project item, which you arent using. My guess is either that is throwing an error or causing weird behavior, or it may be the application instance? When you create an .exe is the application instance the same as when you are running a vi? I am guessing no - you may need to do something special to open the application instance to the development environment.

Okay, just tested - use the project.open method and pass in the project path, rather than the project.projects[] and that should get you what you want. 

[LachlanITG]

---

wrote:

If I am understanding correctly, you want your .exe to interface to development environment controls? Why not use file browser functions? (Call the 'Recursive File List.vi' with the pattern *.ctrl on your project directory) Then you can open the control references using the open VI reference node, I believe. 

---

Tested this out, it will certainly work, I can build the data i need in a packed library and use the library data when the program is an exe. It's not as elegant as i would like but it certainly works.

---

Okay, just tested - use the project.open method and pass in the project path, rather than the project.projects[] and that should get you what you want. 

Tried this as well, Works perfectly in dev even on projects which i don't currently have open, however as soon as i build to executable it seems like it returns an empty reference? wiring the name property node to the reference returns empty in exe but not in dev.

I've attached my test file in case you can see something simple i may have missed 

Seems like on exe I get labview error 7 when attempting to open a project file

[RavensFan]

What path are you feeding in?

Remember that the path to a VI in an executable is different than a path to a VI in development.

Development:

c:\.......\MyProjectDir\MyVI.vi

Executable:

c:\.....\ExeDir\MyEXE.exe\MyVI.vi

You don't need to pass in a reference.  As I said before, you can open a reference to a VI and get the reference to the control from that.

[paul.r]

I just built your VI into an exe and got project items - although I added an event structure to wait for the user to navigate to a project. (If you are trying to run it as is, it is going to try and run with the existing path as soon as you open the .exe, which would be an empty path.)

[LachlanITG]

---

wrote:

I just built your VI into an exe and got project items - although I added an event structure to wait for the user to navigate to a project. (If you are trying to run it as is, it is going to try and run with the existing path as soon as you open the .exe, which would be an empty path.)

---

It's very strange, I added in an event so that it will wait before running however i still get error code 7 (file not found) when the load project call happens. If I select a path to a file which is not a project file then i end up getting error code 1. So labview is definitely recognising that i am trying to open up a project. I tried another pc with just the runtime installed and it came up with the same problem. Could it be an issue with my version of labview? (2015 sp1) 

[paul.r]

Strange.. I am running LabVIEW 2017, I wonder if that property changed between versions.. If you highlight the invoke node with help enabled, it will show if it is available in the run time engine. (If it doesnt show whether or not its available, its probably available.)

[LachlanITG]

---

wrote:

Strange.. I am running LabVIEW 2017, I wonder if that property changed between versions.. If you highlight the invoke node with help enabled, it will show if it is available in the run time engine. (If it doesnt show whether or not its available, its probably available.)

---

It says it is available in the run time engine. I'm going to try on 2017 with an evaluation copy and see if there is still a problem

[LachlanITG]

Ok I've confirmed that it works correctly in 2017, I've updated my copy of 2015 to SP1 f10 but still no luck. I think it is just a bug with 2015. It is more or less exactly what i want but alas I'll have to use a different method as a work around, thanks for your help

[wiebe@CARYA]

Do remember that in an executable, front panels will be removed when possible. This also means VI Server access to controls on the FP is not possible.

To make sure the FP is included in the executable, either:

+ mark that in the build script (you need to dig into the item settings of each VI), or

+ put an event structure in a disabled structure on the diagram. That will trick the compile into not removing the FP.