DanS

I like the idea - well any/all new ideas! (and I have not seen that posted before).

I have not tried it - but my only concern off the top of my head would be: what happens if you wanted to call two namespaced VIs that have the same disk name - and you forced them to compile into the root?

I am guessing that would cause a clash and one would automatically get bumped somewhere else - then how do you find it?

The 9.x can change a lot so I try to avoid messing with it i.e. if you call VIs outside your project, but not a symbolic path i.e. on C and D drive (not that anyone with any experience would do) I am pretty sure another layer gets added.

IMHO I have found use the static ref as a method to point to VIs is much easier, plus I don't have to handle src vs dist path differences in my code.

The simple answer is, I don't. I explicitly set it up so that the exposed VI were all uniquely named.

The whole exercise was meant to try and get the "best of both worlds" vis-a-vis the internal directory structure within an application built in LV 2009.

As you can see from that post I was replying to the first part of your post regarding changes in the 9.x build model.

For your specific use case - you could still use this method by implementing a launcher VI as Shaun mentioned - you only need to know the location of one VI relative to the main VI - but it then it knows all the paths that you need in your build using Static VI refs.

I'm curious, what do you think of my particular approach for solving the problem? In my specific case, I have several VI that I intend to export from my application. By forcing the VIs to be placed in the "root" of the application, I can find the VI's directly by name without having to rely on any other lookup mechanism. I was actually trying to highlight a trick with the application builder, i.e. creating a custom Destination that pointed to the Application itself and by explicitly setting the Destination for any VIs that I want to export. Now I can use a general purpose Call Exported Function VI to access the VI.

I like to use static VI references or relative paths to get around this.

But my problem involved accessing a VI within an executable that is running as an ActiveX server by a separately running VI (not a different VI within the application). I don't see how either of those methods will work.

I really like that they figured out a way in LV 2009 to fix the naming conflict problem in a built application. But an unfortunate side effect is that if you want to run a VI within an executable, you must know the full embedded path. Depending on how your sub-VIs are organized, this path can be unpredictable. You can go back to the LV 8.x file layout, but then you are back to the original problem. I figured out a way to have the best of both worlds--it is possible to force a sub-VI to be saved into the "root" of the application in LV 2009.

First off, you need to create a new destination in your build that is the path of the built application.

Then you need to explicitly add the sub-VI to the project, and set its destination to be the new destination you just created.

Now when you build the application, no matter where the sub-VI is located relative to the top-level VI, its path will always be at the "root".

This was really useful when I was building an app as an ActiveX server, and I wanted to call a VI within the app remotely using the VI server.

I believe there is a MS Windows system call that you can make to tell the OS to lock two windows together. My memory says that I've heard another LV programmer use such a technique, but I know nothing more than that. If you're on non-MSWin systems, you might see if that OS has such a function.

The Windows API call that you are thinking of is SetParent. I have used it in an application, and it works with LabVIEW panels. You just need to get the handles of the parent and child VI's.

There is most likely an issue with the way you allocate the pidl. In fact you should not allocate it as SHParseDisplayName() will do that for you and return the pointer. Allocating a pointer and telling LabVIEW that you pass a pointer to an array is, well .... strange and not right at all.

And at the end you want to deallocate that pidl with ILFree().

Rolf Kalbermatter

You're right about the SHParseDisplayName(). I'm not sure even why I wrote it the way I did. As for the parameter specification for the pidl, I have absolutely no idea how to specify a pointer to an arbitrary structure in the Call Library node. The LabView documentation gives no examples, so I just took my best guess and figured that as long as I was telling it that I was specifying a pointer, that was good enough. I only specified Pointer to Array because the other two options didn't seem correct. I figured that I would just treat the structure as a byte array. If that is incorrect, then what should I be using for that parameter?

I've made my own version of the folder browsing VI. I figured out a way to pass in an arbitrary root folder, so the browsing window only displays the folder and all its subfolders. (This VI is in LV 8.5)

BrowseForFolderEx.vi