Craig, et al,

Craig's answer was the key that let me get past the impossibility of debugging my UFL. So Thanks Much, Craig!

There are a couple other points regarding UFL's, however, that have changed with recent patches to CR8.5 and to the base install of CR9.

First, I had previously discovered that CR now enforces a limit of three (Count 'em 3!) characters to the unique part of the name for the UFL DLL. Whereas the base install of CR8.5 allowed my UFL to be named cruflCRABS, I had to shorten the name to cruflCRB. (Personally, I consider this a giant step back toward obfuscation! Why they couldn't continue to recognize readable names I can't imagine!)

Second, after fixing my CUSTOM class to be a SESSION object, I discovered that now ALL methods in a UFL must have proper types declared, whether or not they are accessed from the report. E.g.: I have several methods I use internally to the UFL for accessing the registry. Since I do not call these directly from the report, I did not bother changing the declarations from what they were in the original class where I first used them. With the original install of CR8.5, these methods were simply not listed as available to CR. No problem there. With the current CR8.5 patches and the CR9 base install, these methods apparently cause CR to refuse to recognize the UFL at all. The solution appears to be to make all internal methods PROTECTED. CR can't object to what it can't see. (Curiously, this does not apply to the INIT, DESTROY or ERROR methods that I override.)

With the above changes, my UFL now appears to be working in CR9!

>Jim,
>
>I tested the files you sent to me. What I discovered was that you have to base your OLEPUBLIC class on Session rather than Custom. In fact, I tried several other VFP base classes. The only one that worked was Session. I'll add this to my list of rules.
>
>