How do I determine VI file specification in Executable?

[blawson]

1) you could use relative path constants (from your launcher to the plugins) to create the plugins path in a way that is independent of RTE/ADE

2) You could use static references and let LV handle it for you.

[Been bitten by LabVIEW]

That's odd that the path property doesn't give you the path of the VI but you have to be within the VI if you don't already have a reference to it.  Another way from within the VI is using the Current VI's Path constant.

If you are doing this outside of the VI though, you might be able to use the Application's All VI's In Memory property, but again, not sure if it will give the path.  I use it to allow me to open references to all the VI's in memory and would be surprised if this functionality is no longer available.  You can then filter out the ones you want by comparing the Connector Panes to one you want.

Let me know if that works out.

A

[Been bitten by LabVIEW]

---

@wwwbrown wrote:

I have read every link available.  Apparently I am missing something.

A: I have source at: C:\DYNAMITE.2010\Core\Applications\Power Supply\Plug-Ins\AGN6700\Initialize.VI

B: I build to EXE at: C:\DYNAMITE.2010\Core\Applications\Power Supply\Public\Build\Example.exe

C: LV reports VI in executable at: C:\DYNAMITE.2010\Core\Applications\Power Supply\Public\Build\Example.exe\Applications\Power Supply\Plug-Ins\AGN6700\Initialize.VI

How do I get C from A and B.  I need to provide C to the Open VI Reference icon to get a valid strict typedef VI reference.

WB

---

Oh, and further, you can get the executable's name and path from the Application's Property node.  Using that in conjunction with a search, you might be able to get what you are looking for.

Personally, I like  blawson's relitive path idea.  Forgot that would be possible.

A

[ww.brown]

All VIs in memory does not give you the relative path inside the executable.

[ww.brown]

The all VIs in memory property does not give the VIs relative path inside the executable, at least not since LV 8.6.

I am beginning to doubt that access to VIs parked inside an executable is a viable option.  The best alternative seems to be a source distribution used in conjunction with a relative path.  I am still looking into using static VI references though I would prefer to do this work with references determined at run-time.

Thanks all.

WB

[Been bitten by LabVIEW]

Well there must be some way to access all the VI in an executable.  I would think too many apps out there would be reliant on this for all sorts of reasons.

Do we have an LV Engineer here?

[ww.brown]

Back in LV 2009, there was a 3rd party workaround using a zip library to access the VI paths in the executable.  That approach no longer works.

There is an eerie silence about this issue.  Maybe it is due to some security issue.  Maybe it is due "operator error" and I am missing something.

It seems pointless to have the app builder offer an option to include VIs in the executable and then not give you a technique to access them at run-time.

WB

[Been bitten by LabVIEW]

Well, you could get the builder to go back to how it did it pre 8.3 (was it?) like was posted previously.  But that means a flat file system meaning if you have 2 VIs with the same name, it'll probably barf. :r

A

[DaHelmut]

Hi,

An executable created with LabVIEW (since 2009 I guess) is a kind of zip file, you can try it, open an executable with WinZip or something similar and you'll be able to list a lot of files inside this executable.

In LabVIEW 2009 you can list all the VIs included in the exe using zip functions like the ones OpenG provides, see http://thinkinging.com/2009/10/02/how-to-list-files-in-a-labview-2009-executable-app/

Since LabVIEW 2010 you can't list the VIs inside an exe anymore because NI did correct this (I don't know why).

With previous versions of LabVIEW the link I gave above explains it.

Regards,

[DaHelmut]

...