Copying a class into a new class library

[AndrewMozley]

I have an existing class library, and a new empty class library in a different project and would like to copy some classes from the existing library into the new library; I would then modify them.

I understand that one way to do this is to open the existing and new libraries in two instances of the class browser, and then to drag the selected class into the new library.

I can indeed attempt this; however I get several error messages, each one stating that a variable referenced in the init() method of the class – e.g. Thisform.Mycolour - does not exist. I can click on OK (several times) to ignore each error but, at the end, no new class has been added to the new library.

It is true that these variables do not exist at the time that I am attempting the copy, but they will exist when the class is instantiated at run-time.

Grateful for guidance.

 

[Mike Lewis]

The way I do this is to open both projects at the same time. In each project, go to the Classes tab. Then drag the class in question from the source to the target.

Using this method, I've never seen the sort of error message you described.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

Keep in mind that copying a class to a different library in this way creates a duplicate copy of the class. That might be what you want.

But if you want to share a class between multiple projects, it is usually better to store the classes in a given VCX which is itself shared between the projects. That way, you will still only have one physical file, and any changes you make to a class will immediately be available to all the projects that use it.

So, you would have a VCX called, say, Common.VCX. And you would use that to hold all the classes you want to share. Then simply add that VCX to all the projects where you want to use it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

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:

http://stevenblack.com/articles/managing-vfp-class-libraries/

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:

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

http://fox.wikis.com/wc.dll?Wiki~VFPVcxStructure.

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.

 

[AndrewMozley]

Thanks Mike

I was trying to copy a single class from one vcx library to another. Not sure that I can do that within the project manager, but let me know if that is possible

Using the class browser, I find that if I comment out the lines in the method which cause the errors, the class browser is quite happy to copy the class to another vcx.

So as a work-around I have tried copying original.vcx to temp.vcx. Then edit the offending method in temp.vcx. I then use two copies of the class browser to drag the class that I want to copy from temp.vcx to newlib.vcx. Finally I edit the class in newlib.vcx to remove the comments from the method.

It works but it is rather cumbersome!

Thanks also, Olaf, for your link to Stephen Blacks notes, useful stuff. Also for the note on the structure of vcx files.

 

[Mike Gagnon]

http://www.tek-tips.com/faqs.cfm?fid=2409

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[Olaf Doschke]

Yes, you can move a single calss as Mike described. You have to expand the library nodes, and then drag the class node from the on to the other lib, but it's simple drag&drop.
The only hting this does not do is also adding the whole parent hierarchy, it has to be in approriate places and that is the major reaso you can't simply move just one class, all its dependencies also have to move.

Bye, Olaf.