Application File Structure + LVClasses and Methods

[durnek60]

Hi Experts!

I'm wondering about, how to create my application file/folder structure.

I've a top level VI, that contains and manage most of my classes but some methods (not all). First of all, I would like to know. if I create an application, and set my startup vi, that contains only an LVclass object its block diagram (only the object, no method exists on the top level vi). When I create my my app, all the methds will be loded into memory, by default or just the class? The reason why I would like to know, is the following. I have some plugin VIs that operate on the parameter Classes, which was created on the top level vi, and sent as a parameter to the plugin vi by (VI Server - Set Control property)

Do I have to set my class and all methods to Source Distribution - Always included filed in orded to use and manage and handle the parameter object?

My Second question is in connection with classes and source distribution. My opinion is, It is good, when I only have one source distribution as an llb. next to my application.exe.

Creating this distribution The always included filed is full of my top level plugin vis and all the rest are included when referred. I have several override methods, of my classes, so I can not merge all of the reffered vis (methods) to one distribution.

Could you tell me, how can you handle this situation? or could you suggest me a way to go?

Thanks in advance!

[Daklu]

When I create my my app, all the methds will be loded into memory, by default or just the class?

When a class is loaded into memory all methods are loaded into memory as well.

My opinion is, It is good, when I only have one source distribution as an llb. next to my application.exe... I have several override methods, of my classes, so I can not merge all of the reffered vis (methods) to one distribution. Could you tell me, how can you handle this situation? or could you suggest me a way to go?

.llb files are old technology and don't work well for distributing classes. Packed project libraries *may* be an option, but there are lots of gotchas and you need to be careful. There isn't really a LVOOP-compatible equivalent of llb files yet.

[jgcode]

.llb files are old technology and don't work well for distributing classes... ...There isn't really a LVOOP-compatible equivalent of llb files yet.

I disagree - (yes, llb's are old) but I like to distribute a single class (or library) as an llb.

Of course, multiple classes (or libraries) would mean multiple llb's for that distribution.

[durnek60]

I disagree - (yes, llb's are old) but I like to distribute a single class (or library) as an llb.

Of course, multiple classes (or libraries) would mean multiple llb's for that distribution.

And how do u handle the overwrite methods? (equal names)

Are your classes in different llbs?

For example: ApplicationDirectory\Resurces\Class_1.llb and Class_2.llb?

[Daklu]

I disagree - (yes, llb's are old) but I like to distribute a single class (or library) as an llb.

Good point, I hadn't thought of that. My classes are almost always contained in a library with other classes and I prefer my distribution format is consistent regardless of the content. Distributing an llb when there's no name collisions and a file system directory when there are name collisions kind of rubs me the wrong way. (This is just my personal preference... afaik there's nothing inherently wrong with doing that.)

Come to think of it, I've been assuming it's not possible to split a lvlib or lvclass into multiple llb files. Is that correct?

[crelf]

I disagree - (yes, llb's are old) but I like to distribute a single class (or library) as an llb.

I think that might be an option for distribution, but not development (eg: can't handle methods in SCC).

[durnek60]

I think that might be an option for distribution, but not development (eg: can't handle methods in SCC).

It seems, there are many reason why should I choose llb, or not...

What are the common solution for these problems?

How do I manage my Classes and methods in development time in order to use SVN?

And Source Distribution?

[Daklu]

What are the common solution for these problems?

I can't claim it's common, but here's what I do:

For development, my applications are designed as components, each component consisting of one or more libraries (.lvlib), and each library containing one or more classes. Each class has a unique file system directory that matches the name of the class. I put the .lvclass file and all methods in this directory. Since each class member must have a different name and I work through the project explorer window instead of the file system, I don't bother creating subdirectory to group class methods. It creates too much maintenance during development. I group them using virtual folders in the project explorer.

I do the same thing with libraries. Each library gets its own directory of the same name. All classes that are members of the library go in the library directory.

My directory trees often look like this:

ProjA\ProjA.lvproj

ProjA\src\MyLib\MyLib.lvlib

ProjA\src\MyLib\ClassA\ClassA.lvclass

ProjA\src\MyLib\ClassA\Method1.vi

ProjA\src\MyLib\ClassA\Method2.vi

ProjA\src\MyLib\ClassB\ClassB.lvclass

ProjA\src\MyLib\ClassB\Method1.vi

ProjA\src\MyOtherLib\ClassA\ClassA.lvclass

etc.

For distribution I just copy the library's directory, assuming it doesn't have any external dependencies.

[durnek60]

I can't claim it's common, but here's what I do:

For development, my applications are designed as components, each component consisting of one or more libraries (.lvlib), and each library containing one or more classes. Each class has a unique file system directory that matches the name of the class. I put the .lvclass file and all methods in this directory. Since each class member must have a different name and I work through the project explorer window instead of the file system, I don't bother creating subdirectory to group class methods. It creates too much maintenance during development. I group them using virtual folders in the project explorer.

I do the same thing with libraries. Each library gets its own directory of the same name. All classes that are members of the library go in the library directory.

My directory trees often look like this:

ProjA\ProjA.lvproj

ProjA\src\MyLib\MyLib.lvlib

ProjA\src\MyLib\ClassA\ClassA.lvclass

ProjA\src\MyLib\ClassA\Method1.vi

ProjA\src\MyLib\ClassA\Method2.vi

ProjA\src\MyLib\ClassB\ClassB.lvclass

ProjA\src\MyLib\ClassB\Method1.vi

ProjA\src\MyOtherLib\ClassA\ClassA.lvclass

etc.

For distribution I just copy the library's directory, assuming it doesn't have any external dependencies.

Thank you very much! I'll try this!

[jgcode]

Good point, I hadn't thought of that. My classes are almost always contained in a library with other classes and I prefer my distribution format is consistent regardless of the content. Distributing an llb when there's no name collisions and a file system directory when there are name collisions kind of rubs me the wrong way. (This is just my personal preference... afaik there's nothing inherently wrong with doing that.)

Come to think of it, I've been assuming it's not possible to split a lvlib or lvclass into multiple llb files. Is that correct?

I also like to use the same as you - Library containing Classes e.g.

But when I distribute it looks like this:

As you can split it all up - I just think of llbs as a folder.

For development I like to set things out pretty much like this:

Where modules (under src) are Libraries, Libraries of Class, or single Classes or traditional modules (e.g. MFVI's) etc...

Curves is the name of an application, each application in the project (only 1 in this case) gets its own directory at this level (i.e. they share Shared VIs, Reuse VIs, and Modules).

[SteveChandler]

.llb files are old technology and don't work well for distributing classes. Packed project libraries *may* be an option, but there are lots of gotchas and you need to be careful. There isn't really a LVOOP-compatible equivalent of llb files yet.

I would like to take this opportunity to pimp one of my ideas on the Exchange - Bundled Project Library. Only 12 votes for something that will make all of this easier?

It contains all the benefits of a packed project library, llb and lvlib. The only reason I don't use llbs is that I can not always use llbs. The way I program these days I get name collisions more often than not.

I have put several ideas on the exchange and out of all of them this is the one I would most like to see implemented.

[Daklu]

Thanks Jon, that's good to know. Couple questions:

1. Your llb file names are prepended with an underscore. Do you do that because of potential naming conflicts between the llb and the class/library name?

2. I assume you have to create a unique source distribution for each llb, and the llbs have to be built before you build the application. Do you script your build process to control the build order?

(There's a hanging curveball for you to hit out of the park.)

3. Why do you have a directory dedicated to Yair?

[jgcode]

1. Your llb file names are prepended with an underscore. Do you do that because of potential naming conflicts between the llb and the class/library name?

Nah, I just wanted to show an example of Library with Classes distributed as llb's.

It was on me at the time, but that example is for reuse, hence the namespacing.

I have played with both, namespacing and not for Plugin Classes, I don't think it matters too much.

2. I assume you have to create a unique source distribution for each llb, and the llbs have to be built before you build the application. Do you script your build process to control the build order?

Well if they are truly Plugins then they do not have to be part of the application build process, only the 'interface' Class does.

However, it could be (both part of, and scripted) - it would depend on the application.

I don't have to create a unique source distribution for each llb, I can do multiple llb's in one source distribution.

3. Why do you have a directory dedicated to Yair?

Very clever