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
