I am developing my first LVOOP app and I can't find an option to copy or duplicate a class. In this app I am attempting implement the Holy-Grail of LV, create controls and indicators on the fly. All of the controls and indicators will be individual LVOOP classes and so far, I have the following class hiarchy.



Brief explanation;

Plug-ins - This class defines all objects I will be able to drop on the FP while the app is running.

Dynamic - All objects that will change while the app is in Operate mode. These will be controls and indicators.

Static - These will be background decorations and anything that has an image that does not change.

Boolean - All dynamic objects whos value is either 1 or 0.

LED - A round LED.

Toggle PB - Round push-button

Toggle SW - A toggle switch.

WEll it turns out that there is very little differnce between "Toogle PB" and Toogle SW" aside from the images associated with true and false. What I would like to do is right-click on the "Toogle SW" calss (in the project window) and select Duplicate class. But that option does not exist.

So far I have had to manually create the new class and then set all of the options and inheritances manually.

If there is no official way to do this, how do others go about cloning a class?

Ben

I know that you can clone a GOOP class just by right-clicking. Not sure if "Save As" would be sufficient for you if not using GOOP. Would inheritance hierarchy be preserved? I haven't tried it yet.

I think right clicking the class and selecting Save As will do exactly what you want. It copies the member VIs, inheritance settings, maintains the directory organization and everything.

This post has been edited by ragglefrock: Jul 2 2008, 05:43 PM

Well it looks like I chose the wrong method of organizing my folders for this to work. I'll try re-arranging the furniture and see if I can get that to work.

Thanks!

Ben

Sorry to bring down the SNR by posting slighty off topic - I suggest you arrange your heirachy using a similar structure that LabVIEW uses internally - that might make your solution a little more intuative:

THe end users will not know anything about LabVIEW so I'm not sure if that will help much.

Back to the issue at hand!

Rather than fumble around trying to get the project to open up without conflicts (that don't seem to go away, So I threw away an hours worth of file save as...)....

How do Y'all organize the LVcass file relative to the VI's that implement the methods for that class so that the "Save As...." on the Class results in cloning it and all that goes with it.

Boy this hurts! But its better to figure this out now rather than latter.

Thanks all,

Ben

PS: If I figure this out, I'll post back with a structure that works.

The easiest thing to do is to have one root folder that contains a class with any number of subfolders for methods, typedefs, etc. I would personally never have a class member at a directory level lower than the lvclass file, and I wouldn't ever keep two lvclass files in the same directory.

In fact, I generally prefer to mirror the lvclass structure in the project on disk.

I agree with these rules.
I've created a "_class" folder where I store all my classes. One sub-directory per class. It acts as a user.lib and I add this main directory to the palette for quick access.

One class per directory. No subdirectories beneath that. Classes specific to a single project are in subdirectories next to the project file. Classes common to many projects are in another directory.

OK thanks to All!

It turns I broke every one of those rules.

I'll call this a life leason and adjust my habits.

Again, Thank you!

Ben

Do I understand that you recommend to classify Public/Protected/Private VIs only using virtual folders in project file and not real folders? Is there a known issue with this particular arrangement? Or perhaps a future one?
I normally like to keep my disk folders about the same as my project files... As Ben says, it's never too late to stop breaking the rules...

Virtual folders are supposed to be just that... virtual. Moving files physically on disk breaks source code control. I don't want to have to do a "perforce rename" command every time I change a VI from public to private, or whatever other organization scheme I may be using for my VIs. I don't want to have to make sure that all caller VIs are in memory so that they're kept up-to-date about the path change of the VI. To me, making the physical structure reflect the virtual structure is no different from putting "_private" in the name of the VI. It causes problems if you ever decide to change how you've got the VIs organized. Once you're completely done with development, you can use "Build>>Source Distribution" to create a particular disk layout if that's desirable for some reason.

This is all just my opinion, not a rule. But, as has been noted, things do work better when you use a tool the way its designers intended. :-)

Now, there are those who advocate the opposite, and for those people, the "disk sync'd folders" exist. I loathe the disk-sync'd folder feature. Why? Because it does not and never can work with libraries (including .lvlib, .lvclass, .xctl and .lvsc). The physical hierarchy and the ownership hierarchy cannot be simultaneously reflected in the tree, and the two features end up fighting with each other. But if you're just using raw VIs, you may enjoy disk sync'd folders. Assuming you're not using source code control, of course. :-(

Maybe tools should be designed as users expect them to work. :-)

Point taken.

Notes to others:

"Rename" is handy for moving your files around.

Use a Source Distribution to pull out only the active files.

If you do something that results the project trying to re-open the old files, check your lvproj file with a text editor for the files it is looking to find, they sometimes get stuck in a section labeled VI's in memory. Just edting out that line fixes that.

Ben