As I stated earlier, when the compiler sees a dependency it'll add the VCX library, and that includes other libraries classes of the library inherit from, so it can cause a whole cascade of added files to the project.
It will include the _gdiplus.vcx, as there must be some dependency. Maybe not important when you only want to use the HTMLlistener which only inherits from a long chain of other listeners going back to the reportlistener base class. But the problem you have when adding the _gdiplus.vcx points out something is weird with your VFP installation. A nesting error exceeding allowed level is about when you make a too deep recursive call or use an expression referencing itself directly or indirectly cause more than 128 calls on the call stack. I don't see how that could happen when you just add a library to the project, but if you use a framework, which even hooks into the development time acting on the PJX via a project hook, that might cause such an error.
Aside from that and totally independent, you always have a problem using FFC with VFP installed into program files, as the program files folder is read-only protected and while the VCXes contain both source and object code and need no compilation, the PRGs coming in the FFC folder don't all have their compiled FXP file and recompile all will also cause compilation of PRG and VCX source memos, so you end up with files in the VirtualStore folder. You should give users permission to write into the VFP home folder to solve this better than Windows solves this with its redirection of file writes into VirtualStore folders.
Or simpler: Install FVFP into a nonsystem folder like c:\Users\Public\VFP
And then, another thing about copying FFC libraries into your own local folder is, that it does reference back to the VFP installation folder with Home() references, which makes copying the FFC folder into your project folder fruitless in terms of how things are instantiated at design time and runtime.
You might also need SP2 to fix some issues.
In summary, I'd recommend what also wOOdy (Jürgen Wondzinski) wrote about the VFP9 installation: Install into a separate folder, get the SPs and also VFPX project add ons (Sedna and more, Thor, for example, as a basis for anything integrated into that IDE menu extension).
And then when you use FFC classes, use the ones from the installation folder, which then also is writable and doesn't cause problems when you recompile all.
If you extend or edit FFC classes, that's a bad idea when other projects or third party modules depend on originals, you better then Do copy the FFC folder, but even before you make the first edits there, you'd need to fix all backreferences using Home() both in code and (if so) in any expressions stored in properties, too. And that'll be tedious, so it's not really recommendable. If you need to change something, even a known bug, inherit the original class into a child class and change the child class, that's the OOP way of doing this, as it keeps original code untouched.
I actually don't assume you fiddled with the VCXes, but maybe that explains the recursion level error. The simplest thing to do is starting with a VFP9 installation from scratch. First, create a destination folder like C:\VFP9, then start the setup, because within the setup, at the step you're asked to confirm the usual install path c:\program files (x86)\Microsoft Visual Foxpro 9\ you can't create a new folder, you can only enter a path to an existing folder. But you can do at least that, and have no complications with UAC and file virtualization the OS does since Vista.
Bye, Olaf.
Olaf Doschke Software Engineering
