what is the logic for the behavior of LV9 when opening vi references?

[dbrewe]

---

tst wrote:

---

dbrewe wrote:

"But with VI libraries and LVOOP this had the problem that multiple VIs could end up with the same name..."

I'm not clear what this means exactly. My first response would be that it doesn't seem like a good idea in general to use different portions of code with the same name in a single application. I'm surprised this is even possible.

---

Libraries serve as a namespace mechanism, so you could have a VI called init.vi in the library mydevice.lvlib instead of having something like MyDevice_Init.vi. For some behaviors, such as overriding in LVOOP, this is even required (e.g. dog.lvclass:walk.vi overrides mammal.lvclass:walk.vi).

OK, the oop approach is something I have not tried to use, and I should probably try to understand it. Thanks for the explanation.

---

The assumption appears to be that the organization of your source files is an essential ingredient in the application that is built.

---

Only if you're relying on it. For instance, if you call VIs dynamically without explicitly building them, their dependencies would not be built either and might not be found. This doesn't seem to be your case, since you say the 8.x style works, so I'm guess your case is simply a matter of accounting for the location of VIs relative to each other after the build. Usually, this isn't a problem, but if you're using dynamic calls, you have to understand where LV will place each file. In most cases, people don't use dynamic calls or include the dynamic VIs in the build, thus allowing LV to take care of all the path issues.

Well, I'm not sure I stated my original comment very well. As far as I can see, my application depends on the location of the files in my development directories if I build my application w/ the LV9 file structure.   For example, if I try in my LV9 development environment to open a reference to "Run Mono.vi" from "Control Panel.vi" and give the open reference vi a relative path consisting of the vi name, LV tells me it can't find Run Mono.vi  at  <my absolute path to Control Panel.vi>\Run Mono.vi. So, as far as I can see, I have to either place Run Mono.vi in the same subfolder as Control Panel.vi,  or give the open reference vi an absolute path to Run Mono.vi (or  a relative one derived from the relative path between Control Panel.vi and Run Mono.vi).  In either case my application now depends explicitly on the location of the two vis in my development environment. In my development scenario, I don't care, because I build the application which puts everything into the executable, which I can deal with (pre LV9 file structure).  As far as I can see, dynamic calls are crucial in my application, as I want to spawn off my many  subsystem control panels from a central location and I don't know any other way to do it - I can't imagine trying to keep track of and pass absolute paths for all the dynamic vis I need to call. 

---

Before LV 9 it never occurred to me that I might actually have to worry about being able to find vis inside the executable. 

---

I think this might be the key. Before LV 2009, the EXE had all the files internally as a single folder. That's why library files were placed outside - some of them had the same name and couldn't be placed in the same directory. In a 2009 EXE, the directory structure is preserved inside the EXE, and I have a feeling your code is relying somewhere on having to strip only once (or something along those lines). If you're interested in debugging this, the easiest is probably to place an indicator showing the path where things are expected to be found.

---

This is essentially correct. My previous naive picture of what was happening during the build was that the build process was basically acting as a linker to provide the runtime environment with the locations of the code for my dynamic vis in the executable so it could find them when I opened the reference - that's why it originally kind of mystified me when my application failed and started looking at the errors I was getting!

[tst]

I think I understand now.

I didn't realize that you don't ever run the entire app in the IDE. This explains your issues - in 8.x, the files are stored inside the EXE as a single folder (unless there are multiple files of the same name), thus doing option 2 in my illustration above always works, because the files are always next to each other.In 2009, the original folder structure is maintained inside the EXE (which is basically a zipped folder), so the files aren't next to each other anymore.

For most people, the exact structure of an EXE doesn't matter at all, since LV takes care of saving and relinking all the dependencies. When you do dynamic calls, however, you are expected to handle at least some of this stuff yourself.

If you don't want to keep using the 8.x solution, you can do one of several things. Here are two examples. On the top you have a VI which returns the path to the folder with all the dynamic VIs (it can simply return the path to the folder it's saved in). You can then use this path to build the path, which would work both in the IDE and the EXE.

The second option shows using a static reference , which allows you to run them in parallel, but also causes the VI to load at edit time, which I understand you don't want.

[dbrewe]

Thanks for the suggestions.  I think I will use the 8.x solution for now as it doesn't require me to change my applications, but the ideas and added information are something I think will prove useful.  If I had to describe my use of LV, I would say that I really don't use it as an execution environment at all, but rather almost exclusively as a development platform for my standalone applications (which BTW, for the most part don't actually directly control hardware but use various network protocols to act as clients of servers in my distributed system).  A key point I had no clue about before was that a LV-built executable isn't an executable per se, but is, as you mentioned, basically a self-extracting zip file. This will inform the way I approach things in the future.  

[tst]

An LV EXE is NOT a self-extracting ZIP. To understand the concept, you need to understand the way LV executes code. Basically, each VI is compiled into machine code as you edit it, and that machine code is saved inside the VI. When it comes time to do actual work, this is the code that's called and sent to the CPU. This works basically the same in the IDE and an EXE (which allows you, for instance, to run VIs from an EXE without requiring any compilation step, since the VIs are already compiled). When you build an EXE, LV basically takes all the VIs, saves them into the EXE and relinks them so that the links correctly point to the files inside the EXE. The EXE is now a hierarchy of VIs which the RTE can run.

As I said, all this is only required knowledge if you do certain kinds of apps. Incidentally, I also use LV to compile stand-alone apps. It's just that most people test the apps in the IDE before building them, which is what threw me off in your case.

[dbrewe]

---

tst wrote:

An LV EXE is NOT a self-extracting ZIP. To understand the concept, you need to understand the way LV executes code. Basically, each VI is compiled into machine code as you edit it, and that machine code is saved inside the VI. When it comes time to do actual work, this is the code that's called and sent to the CPU. This works basically the same in the IDE and an EXE (which allows you, for instance, to run VIs from an EXE without requiring any compilation step, since the VIs are already compiled). When you build an EXE, LV basically takes all the VIs, saves them into the EXE and relinks them so that the links correctly point to the files inside the EXE. The EXE is now a hierarchy of VIs which the RTE can run.

As I said, all this is only required knowledge if you do certain kinds of apps. Incidentally, I also use LV to compile stand-alone apps. It's just that most people test the apps in the IDE before building them, which is what threw me off in your case.

---

I stand corrected. I misinterpreted your phrase "the EXE (which is basically a zipped folder)...".  The thing that is still counterintuitive to me is that as I understand the process,  LV really does the linking in the development environment.   In other words I have to explicitly resolve all my references in the development environment  - if they aren't resolved in the IDE they aren't resolved in the EXE, unless I guess correctly what path specification that will work. This (guessing I mean) is possible w/ the older exe structure - but seems pretty impossible in the LV9 exe structure.

[dbrewe]

---

dbrewe wrote:

---

tst wrote:

An LV EXE is NOT a self-extracting ZIP. To understand the concept, you need to understand the way LV executes code. Basically, each VI is compiled into machine code as you edit it, and that machine code is saved inside the VI. When it comes time to do actual work, this is the code that's called and sent to the CPU. This works basically the same in the IDE and an EXE (which allows you, for instance, to run VIs from an EXE without requiring any compilation step, since the VIs are already compiled). When you build an EXE, LV basically takes all the VIs, saves them into the EXE and relinks them so that the links correctly point to the files inside the EXE. The EXE is now a hierarchy of VIs which the RTE can run.

As I said, all this is only required knowledge if you do certain kinds of apps. Incidentally, I also use LV to compile stand-alone apps. It's just that most people test the apps in the IDE before building them, which is what threw me off in your case.

---

I stand corrected. I misinterpreted your phrase "the EXE (which is basically a zipped folder)...".  The thing that is still counterintuitive to me is that as I understand the process,  LV really does the linking in the development environment.   In other words I have to explicitly resolve all my references in the development environment  - if they aren't resolved in the IDE they aren't resolved in the EXE, unless I guess correctly what path specification that will work. This (guessing I mean) is possible w/ the older exe structure - but seems pretty impossible in the LV9 exe structure.

---

PS I guess what would fit my particular way of doing things would be for the application builder to provide the option for more-or-less the equivalent of a static build.

[tst]

I think part of the issue is that you're projecting from C terminology unto LabVIEW, thus confusing yourself.

I'll try again.

Each VI holds its machine code inside the file. This is what allows it to be executable.

Each VI also holds the relative path to any VI it calls (so if the subVI is in the same folder it would be ..\subVI.vi and if it's in the parent folder it would be ..\..\subVI.vi). This allows the VIs to know where to find each subVI and, assuming the VI is there, to load with no issues.

These are true for any VI, either in the IDE or in an EXE.

The relinking I was refering to was simply taking the VI hierarchy and resaving it inside the executable. You can perform the same process by creating a development distribution or a DLL. Again, there's no special compiling involved (other than removing the source code and optimizing out debug code, etc.). It's just saving the VIs inside the EXE.

The static build you want is basically the normal way you build an app in LV - you have all the VIs in the code and they get included automatically in the EXE. Your case seems slightly more complicated, since you're using dynamic loading, but since it's working in 8.x, I assume that means you're already including all the dynamic VIs in the build, so all you need to do is supply the path where they'll be. That shouldn't be too hard, since that path is not chosen randomly, but reflects your original hierarchy (although you could probably also instruct the build to direct the dynamic VIs elsewhere, but I never tried).

[dbrewe]

---

tst wrote:

I think part of the issue is that you're projecting from C terminology unto LabVIEW, thus confusing yourself.

---

Well, I kind of think part of the issue is that you're projecting from conventional LabVIEW practices and typical LV application structure. I believe I understand the gist of what you're telling me, whether I've stated that clearly or not. At the risk of beating a dead horse I'll try one more time to explain my original point from way back:

If I want to build an exe with the LV9 file structure, and I move files in my source directories, I have to change my program, which I do not using the older file structure - and I don't like the new behavior. That is really all I started out trying to say. To try and explain:

For example, if I have Run Mono.vi at  <path to Run Mono.vi> I have to open a reference using specifically that path, or perhaps a relative path assuming a particular organization of my source directories. If I want to use a version of Run Mono.vi at <other path to Run Mono.vi> I have to now open a reference using specifically that path if my built application is to work. I don't really want to explain why at the moment, but it is also convenient to be able to open the reference to a particular vi from different locations in my application, and that means I would have to make even more changes. This is not necessary using  the older exe file structure and the way I have written my applications (I do have to change my project file). <other path to Run Mono.vi> can be anywhere and I don't have to change my program. I can open references to any number of vis (as I said ~60 or more) from anywhere in my application, using the same generic base path, which in the pre-LV9 file structure basically resolves to "inside the executable".  If I try and open the reference to any of my dynamic vis using that base path in the development environment it won't work, but I don't care, because I can run and test all my dynamic vis separately, and the built executable works. I now understand more about why that is the case, but that is kind of beside the point. Doing it this way appears to be foreign to most LV users, but in my opinion it provides very useful flexibility and simplfies things in that I can make the same exact call to open any reference.  I am perfectly happy using the "8.x" file structure for my executable, but calling it "8.x" implies "old", which makes me assume NI will stop supporting it sometime, and I would dislike having to change my development habits, altho I think I know how I would be able to go about doing that. 

At this point if I haven't got my point across it's not going to happen, likewise if I haven't understood you either. Thanks for your efforts in discussing this. 

[tst]

---

dbrewe wrote:

Well, I kind of think part of the issue is that you're projecting from conventional LabVIEW practices and typical LV application structure.

---

Yeah, but I would think that was reasonable if you take into account that a) we *are* dealing with LabVIEW and b) I do understand how it works 😉 .

---

If I want to build an exe with the LV9 file structure, and I move files in my source directories, I have to change my program, which I do not using the older file structure

---

Yes, but only because you wrote your app in a very specific way which relies on a particular property of the EXE and which doesn't work in the IDE. The code which allows you to handle all cases cleanly is pretty simple code. I don't know how far forward NI will continue supporting the 8.x flag (it's there to support apps which rely on this behavior, such as yours, and it may well still be supported 10 years from now), but you should take into account that if you're doing something like this, you have to understand how it works to able to use it effectively.