Changing location of a class library 1

Changing the reference to the class within the project is not enough. You also have to change it in the form.

If you open the form in the form designer, click on the date picker, then look at its properties, you will see a pair of properties named Class and Class Library. This is how the form knows where to find the class.

These two properties are read-only, so you can't edit them directly. Instead you must remove the date picker object from the form and then add it back (from its new location). Of course, when you do that, you will lose all the property settings and method code that you might have added to the object, so be sure to make a note of these before you start.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

If you are likely to be doing this sort of thing often, I would recommend Rick Schummer's HackCX tool, which makes moving class libraries around very much easier - and avoids having to reset the properties and methods.

I believe there is also a tool within Thor which can help with this, but I don't have any personal experience of it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

I agree with everything Mike says.

On top of that it's not a good idea to have new class libraries in VFP Home directory like this:
[pre]C:\Visual FoxPro 9\ffc\ClassesTerceiros\ctl32_Doug_Hennig.[/pre]
Even if you subclass a class from the ffc (foxpro foundation classes), you shouldn't add own directories or class libraries into the home folder, but have your own classes in your project folders or a root folder you use in multiple projects.

It's not a good practice to mix something individual with something FoxPro. While it works, if you give yourself all necessary permisions or install outside of the Program Files system directory and causes no headaches with UAC or permissions, this way, it's still not an extension of VFP itself. If Thor does add it's app and class files within the VFP Home() installation directory, that's another thing. ctl32 is from Carlos Alloatti and the topic is ActiveX controls and more. I would agree it enhances projects and could be seen as an extension of controls available in all your VFP projects, yet it doesn't extend VFP itself and the IDE, so it's a controls library that should better be organized outside of the VFP Home() directory.

I'm not saying you have to reorganize this once more, as you already did have trouble with that, and the trouble you had in reorganizing would also have been trouble when the initial location of the libraries would have been outside HOME(), so that's not the point. For reusability purposes a central place is okay, so why not in Home().

Well, I would recommend something that at first blush looks like no good OOP style and incorporate any additional libraries into a project directory where you use it. To reuse libraries in further projects you can copy them over into the next project directory. That way any changes you make to a libarary will only act local and other projects don't inherit the improvements, that's the bad OOP style. On the other side you don'T cascade the need to test all your projects because you make some central change affecting all projects. If you need to do a fix, you need to make it multiple times, but in general in my experiene such separation of the different projects helps more than it hurts. Because each individual project stays untouched until you share things by intention.

And think about what this means even for your subclassing. The paths of your own subclasses will be relative to the libraries you use, so whe you start a next project, you can copy over the third party librarie and your own enhancements into a new project, start from the same stage and keep all your enhancements intact without pathing problems, as paths are all kept relative to the project home directory.

Even if you like to centralize some libraries you intend to use in multiple, if not all projects, like FoxyPreviewer, then centralize them outside of the Home() directory, still. There's a good reason the developers of many such generally usable libraries made projects they compile into apps, so you only have to copy over an app into your own projects. That also makes things easier.

One thing you have to know about pathing of classes. In the information bar at the footer you show in your screenshots you'll always be shown absolute paths, the \...\ in your screenshots are just because of path shortening. If you use a vcx or scx as a table, you'll see the classloc memo will contain relative paths, where possible. And that allows easier relocation, as long as relative locations are the same, you can easily move a whole project without any location paths breaking.

On the other end, absolute paths would also stay valid, as long as the referred librries stay where they are. The bad case is having things in HOME() and projects on drive C:\ outside HOME() still referring to libraries in Home() with relative paths, though you only move a project, not the library. Or, as in your case, you move a library that was referred to in projects and forms, and thereby loose the references.

So all in all, a rule of thumb is reorganization of locations is something you only do when you set up a new project. And do it so, that any old projects also don't suffer.



Chriss

I think one more top priority thing to know is that changing locations of class libraries is not a usual thing to do and there is no inbuilt IDE tool for that. Such things, more often just renaming variables or properties, are in the topic of refactoring, and other IDEs have tools for that, the VFP IDE not. Then there is HackCS, as mentioned by Mike Lewis, and the name makes it pretty clear that doing such things in VFP needs a "hack", un unusal and unelegant way of getting it done anyway, against all odds.

Chriss

I undestood, Mike, I will have to put the date picker again from its new folder in the form, and with all custom properties.

Chris, that is a good point, so I will change my custom class folder to D:\W\ThirdClasses, far from VFP Home folder. Is this a good option?
Note: D is my drive for projects, \W is the folder for Windows projects. In the W folder I have many project folders.

Thank you,
SitesMasstec

Mike, I have not change the directory.

I did the following (without knowing it would solve the problem of changing custom class folder)[tt][/tt]:

- I opened the form FORMRESERVA6 and when I run, the VFP asks to Locate, then I inform the new location of the class and it runs fine.
- Then I opened the form FORMRESERVA6 and did File, Save As, FORMRESERVA7, and Quit VFP
- When I open VFP again and run the form it runs fine, without asking me the location of the class!

Thank you,
SitesMasstec

Yes, that's a known mechanism, you're asked for a location. Buzt imagine you'd have used the datepicker on 40 forms and need to amend all of them.

There's nothing that goes through all forms/report/classes of a project and change location of all instances of the same class.

Chriss

Well, fortunatelly it is my first project I am using CTL32 class library (by Carlos Alloatti; Doug Hennig just produced a good documentation about this library, I had wrongly thought he was the author of the library).


Thank you,
SitesMasstec