I can second Mike, you don't do this in the class browser, you do this in the project manager.
You rather copy all class related records that way, and have to take care all the parent and parents parent classes are also in the same relative location, which makes copying classes this way a risc.
One of the approaches to work with different compositions of classes in different projects is apply the soft rule to only have one class per lib. I rather like the library nature of classlibs and live by another rule to not separate a family of classes, unless there is a good reason for separations.
And to use the same libs in other projects, the first and easiest thing to do is copy the whole libs folder. Then restructure from there, not from the separate project into new empty libs. So I rather copy a classlib.vcx and delete classes I don't want in the new project. Having all VCXes in one lib folder also helps to enable moving end point classes around, classes not (yet) inherited by child classes. Other classes better stay where they are, because moving them means the child classes become orphaned.
Want to have more good hard rules (things you can't bend, break, major rules to live by) and soft rules (good practices, guidelines)? Read this from Steven Black:
He also wrote share.prg, a class browser add-in allowing to create a new single classlib from the classes you want to share or reuse in a new project, putting in all necessary dependencies into that same new vcx. Not my way of achieving my goals, but doable. Doing it that way you can end up with many very different level classes all in one vcx, against the major other paradigm to keep every class on its own. On the topic of the number of classes per libs, Steven Black has the position to make a compromise of keeping things packaged as necessary and keeping number of classes per lib as low as possible at the same time, you can only make a compromise between those two rules and share.prg has a totally different intention of really sharing some class with others, not within a project with multiple developers, not reusing in a new project, but sharing with the community. So actually this tool is a hack to share some class and don't get busted by not sharing any dependencies. This has nothing to do with the class library management and framework build up he describes very well, so I recommend you don't use that for your purpose.
Last fact: when moving around parent classes, further classes inherit from, you have to mend the classloc values in the inheriting child classes to get them fixed, therefore USE the VCXes of the child classes. This code checks the classloc of all project vcx classes, so you can have an integrity and missing dependencies check:
Code:
Local loFile
Clear
For Each loFile In _vfp.ActiveProject.Files
If loFile.Type="V"
Use (loFile.Name) In Select("curclasslib") Alias curclasslib
Select curclasslib
Scan
If !Empty(curclasslib.classloc) And Adir(laDummy,Addbs(Justpath(loFile.Name))+Alltrim(curclasslib.classloc))=0
? "classloc not found in library", loFile.Name, ",class", curclasslib.objname, ",parentclass", curclasslib.Class, "wrong path:", curclasslib.classloc
Endif
Endscan
Endif
Endfor
This will list vcx filename, class and the classloc within the class definition, which is not found there on hdd, so these are the classes to care about their parent class and it's classloc. If nothing is listed, the projects libs integrity is fine from that perspective, you still could have errors pointing to a parent vcx not having the parent class in it, or having a wrong version of it. That's not checked by this routine and the latter can't be checked anyway.
And to state the non obvious: In a vcx record objname is the classname, class is the name of the
parent class, of which objname inherits, so this is not as you'd normally expect from instanciating classes, where the name is just the instance name, typically the name of the variable storing the object reference or the name of the object on a form, ie a controls name, class is the instanciated classes name, and parentclass is the parent class name, also see
The field naming was probably choosen this way, as the most records of compound classes like form classes - having lots of control - are really not about classes, but instances of other classes/controls within the classes. In the end this code is only about revealing not found classlocs of parent classes and thus revealing orphaned class definitions.
Bye, Olaf.
