8.x file layout

[Cat]

Here's one most of you probably haven't thought about for a few years.

I built an application for someone else, and when the exe was run on their computer, it started complaining about missing vis. I realized this probably meant the "Use LabVIEW 8.x file layout" button got unchecked somehow, so I fixed that and all was fine.

Which started me thinking...  Other than the issue LV 8.x and earlier builds have with vis with the same name, is there any technical reason to NOT use the LabVIEW 8.x file layout when making an executable? I don't use LVOOP, and think it's Bad Programming to have two vis with the same name in the same build (either they have slightly different functions, and therefore have different names, or it's the same vi living in my code reuse tree, or maybe it should be a polymorphic vi, etc).

I'm going thru a big code cleanup push and am wondering if this is something worth the effort of "fixing" in my 2500+ vi and 25+ exe library.

[hooovahh]

So do you still use the 8.x layout on all applications built?  I haven't used the 8.x layout since 8.6, and yes I do believe the only real benefit comes from when you have two VIs with the same name in different libraries, it isn't necessarily a LVOOP thing.  There maybe other benefits that NI has made into compiler optimizations that maybe only effect newer layouts, but only NI could say for sure. 

I may have a library that reads an analog signal on one piece of hardware and so to organize it I name the VI Hardware X.lvlib:Read Analog.vi  I can then have another library with another name Hardware Y.lvlib:Read Analog.vi  Having two VIs named Hardware X.lvlib:Read Hardware X Analog.vi and Hardware Y.lvlib:Read Hardware Y Analog.vi seems unnecessary when the library name already states what hardware it is for .  As you are probably aware the flat layout of 8.x means they can't be in the same folder so more folders are made to fix this, where in the newer layout folders exist and so these VIs can reside in the EXE with the same folder structure as on disk.

[Cat]

Yup, all my executables are in 8.x layout.

I will admit the one time this has been an issue was when I used two hardware drivers that were in lvlibs, and they both had an "Init.vi". I just renamed the two vis and went on happily.

I haven't seen a need to use lvlibs. I am currently on a team of one, and I only distribute exes, not source code, so the public/private aspect of lvlibs hasn't been necessary. I organize via directories.

I guess I gave up on LabVIEW libraries back when one of my llbs went over 1.44MB and I couldn't fit it on one floppy anymore. :-)

 

[hooovahh]

An LLB is not a library.  An LLB is more like a flat zip than anything else, and name space does not get modified.  Your example of Init is a perfect one where libraries from all kinds of sources use the same Init, Configure, Read, Write, Close etc functions.  Editing hardware drivers in your project is no problem, but editing ones in vi.lib, or inst.lib can cause more issues due to the distribution method.  Update a package, and all the changes you made went away.

If you organize via directories, then this is also a reason to consider the newer file structure since then your EXEs will have the same folder structure you have on disk, and doing a function like reading a VIs file path (given a reference) will tell you where on disk that VI came from.  This can be useful when logging errors because you can log the full path to the VI that generated the error.  Or the relative path from the EXE to where the VI is in the EXE.  

In the end it is of course up to you but I've found the new structure very helpful over the years.  Yeah you need to know that a single strip path won't bring you to your EXE, but I use the OpenG function that is Current VI's Parent Directory which will keep stripping the path until a directory is found which works in both the 8.x and newer structure.

You should get one of those super huge floppies, I hear they store 2.8MB.

[Tim_S]

2 minutes ago, Cat said:

I guess I gave up on LabVIEW libraries back when one of my llbs went over 1.44MB and I couldn't fit it on one floppy anymore. :-)

You're using those new-fangled 3.5" things, aren't you.

The new file layout was much better when distributing application after report generation toolkit went to LVOOP. Even if I don't use objects, so many shipping things things I use are LVOOP that I don't check that box.

 

[Cat]

Ah, the good ole days...

I only use the S&V toolkit, which I purchased long before OOP was a gleam in NI's eye, and never had a need to upgrade. Other than that, I use very little code that I didn't write (instrument drivers and OpenG being the major exceptions).

This means, of course, that a lot easier ways to do things have probably been developed over the years, and I'm just too unaware/lazy/stubborn to switch over.

hooovahh, I think you've convinced me to at least build a few of my exe's with that 8.x box unchecked and see how horrible it's going to be to "fix" it. Or I can just leave it as an exercise for my replacement...

 

[ShaunR]

1 hour ago, Cat said:

Or I can just leave it as an exercise for my replacement...

Retiring? Promotion? Sabbatical? Management?(cringe)

[Cat]

7 minutes ago, ShaunR said:

Retiring? Promotion? Sabbatical? Management?(cringe)

According to the calendar, I'm eligible to retire in 1 year, 1 month, and 1 day. I'm doing the code cleanup for my (so far hypothetical) replacement. Or I just retire, and come back the next day as a contractor for twice what I'm making now. :-)

[Tim_S]

57 minutes ago, Cat said:

According to the calendar, I'm eligible to retire in 1 year, 1 month, and 1 day. I'm doing the code cleanup for my (so far hypothetical) replacement. Or I just retire, and come back the next day as a contractor for twice what I'm making now. :-)

Isn't that standard operating procedure to do that four or five times?