"Get VI Dependencies" VI method identifies Express VIs (LV2010,sp1)

[550nm]

Greetings,

      It seems "Get VI Dependencies" may include "paths" to Express VIs.

The name of the [Express] VI is "0" and the calling VI is in the path.

Example path: "<myFolder>\<myVI.vi>\0"

Not sure whether this is expected behavour, though, it's inconvenient while processing a VI hierarchy! ;^)

-

[Pachi]

550nm,

This is expected behaviour. Since Express VIs are also VIs, they will be listed.So will controls and type-defs that you create.

Regards,

[550nm]

Prashanth,

      While Controls can be explicitly excluded from results,  Express VIs cannot, yet, Express VIs can't be "Opened" and tested  - "is this an Express VI?". They merely result in a useless path that the programmer must make an exception for.

I doubt a useless path is "Expected behaviour", though if so, then the switch to exclude them is missing.

 

[Broken_Arrow · Accepted solution]

Two ways around this:

1) Right-click on the Express-VI and Open Front Panel >> Convert it to a standard VI, and name it something useful.

2) Don't use Express-VI's.

[550nm]

... third option,

ignore paths that end "<someVI>\%d"

Broken Arrow, Thanks.

I really dislike  Express VIs, but how else do you get a "File Dialog"?

EDIT:

OK, when opened/saved, there are still "express" calls into VI.lib, but all the paths are normal.

Thanks again.

[Broken_Arrow]

---

@550nm wrote:

I really dislike  Express VIs, but how else do you get a "File Dialog"?

---

To find a plain-Jane function for that, do a search while on the block diagram for "file dialog". You will find the Express VI, and a function called File Dialog - which is at the core of the Express VI if you dig down enough.

Use that core function as-is, or use it to write your own File Dialog VI for your needs. No Express VI's Needed!

[550nm]

---

@broken Arrow wrote:

... No Express VI's Needed!

---

OK.  Had to do the "Open Front Panel" trick a couple/few times, but there it is - the good-old "FileDialog" primitive,  (oddly absent from File palette...)

Perfect!  Kudos!

[_Pachi_]

---

@550nm wrote:

Prashanth,

      While Controls can be explicitly excluded from results,  Express VIs cannot, yet, Express VIs can't be "Opened" and tested  - "is this an Express VI?". They merely result in a useless path that the programmer must make an exception for.

550nm,

As broken Arrow correctly pointed out, Express VIs can be opened and used as normal subVIs, and hence it makes sense to include them in the paths returned. As far as LabVIEW is concerned, it is still a dependant VI. I'm glad you found the primitive you needed, but it concerns me that you dislike Express VIs. We welcome your feedback on how you would like it to be. 🙂

Regards,

[550nm]

---

@_Pachi_ wrote:

---

@550nm wrote:

Prashanth,

(snip) , but it concerns me that you dislike Express VIs. We welcome your feedback on how you would like it to be. 🙂

Regards,

---

Hi Prashanth,

      Don't be concerned!  Express VIs make it easy to obtain functionality, however, if a value is placed on the clarity of code - being able to understand a diagram "at a glance" - then Express VIs often hide critical logic and parameters from the source-code.  For instance, the "File DIalog" primitive doesn't convey "Selection Mode", the "Curve Fitting" Express VI doesn't have an input for the "Model" (a fairly important parameter.)

I don't like diagrams which are unnecessarily difficult to understand, so, don't like Express VIs!

Cheers!