LabVIEW
Use LabVIEW 8.x file layout
The 8.X format is a flat hierarchy. So if you have OOP that uses dynamic dispatch, you will have multiple VIs with the same name. Well, that will cause a file conflict in the 8.X format. Same thing if you have multiple libraries that each have a VI in it with the same file name.
In the 2009 and later format, the format basically became a zip file (I am over simplifying here). So you have an actual directory structure. This avoids the conflicts mentioned earlier. It also makes life a little easier if you are dynamically calling VIs using relative paths (it doesn't change, unlike the 8.x format).
So why use the 8.X format? I think* it is a little faster to load. Enough for you to care about? Not likely.
*I have no actual proof of this. This is a derived conclusion based on how the llb format works.
@crossrulz wrote:
So why use the 8.X format? I think* it is a little faster to load. Enough for you to care about? Not likely.
I "THINK" it is unlikely to be faster. The LLB archive format isn't exactly optimized for fast loading. And anyways it's a mute argument. If anything about runtime load performande is going to be improved, the modern format will get all attention and the LLB format will receive 0.0% attention. If in the process the LLB format might proof to cause problems it likely will get axed rather than improved.
So the decision is not so much about optimizing micro performance but about choosing an old legacy format versus the more modern and future proof format.
Okay yeah the OO reason is a good one, but let me make a more basic example that I think is also a common one.
Lets say I download some cool library from the tools network. This library can do things like read and write .DOCX files (this is just an example). This library contains VIs like "Open.vi" and "Close.vi". Other libraries may also have "Open.vi" but they are part of a different library. And in memory these names have the library appended. So my VIs name in memory is actually "Cool Office Library.lvlib : : Open.vi". This way LabVIEW can distinguish between the VIs that have the same name on disk, but are part of a different library.
Now it should be obvious that the "Open.vi" from one library cannot exist in the same directory as another "Open.vi" even if they are part of different libraries. Windows simply doesn't allow you to have two files of the same name, in the same directory.
And this is where the file layout comes in. In 8.x and older the layout was flat, putting all VIs needed for the EXE into a single directory. This would mean attempting to put my office "Open.vi" in the same directory as all the other VIs. In 2009 and newer this is handed by making an EXE that isn't a single directory, and instead it is layed out more or less like it is in Windows, where one "Open.vi" can exist in one directory, and another in another directory.
So if you choose the 8.x layout, and you have multiple "Open.vi" files, it will place them outside of the EXE without any block diagram. This gets messy because now you EXE isn't the only file you need, you also need the support directory some times called "Data". In the 2009 and newer layout all the VIs can be in the EXE in a nested directory structure. Generally just don't use the 8.x layout unless you need to, and really you should need to. Having that not checked helps fix naming collisions.
