>Bob,
>
>This is expected behavior and a really big reason why I like OOP over the old procedural approach. Once you have made a call to your global routine, that routine calls the report, and subsequent function calls are processed using the procedural hierarchy from the perspective of that global routine. I ran into the same situation in exactly the same circumstance (global reporting module) in 2.6.
>
>With OOP and subclassing, statements like loReport.GetPend() run the way you expect (want).
>
>Randy


Hi Randy;

In this conversion project, some of the system is being re-written and some of it is still the original Fox 2.6 code. We need to update at least a portion of the APP and release it before it can all be re-written. The data is 99% SQL Server (imagine a fox 2.6 app that runs against SQL Server with over 5 GB of data - and then imagine the conversion issues!) Anyway, they do a simple REPORT FORM ... TO PRINT and I merely wanted to replace this call with a DO FORM REPORTER WITH which is a common form I have that manages report output. This is a modal form so the program that calls it should be active and in the 'procedure hierarchy'; at least, so I would have thought. I was going to provide a little extra functionality without any fuss. My Form has never failed me before whenever I have done this replace, until now. I could create a custom object with methods etc.... but no one is paying for that! The program and report form went through a functional conversion and they do work fine but it is an issue I will have to keep in mind if I have reports that reference functions in the calling program but are actual printed from a Form module!

Bob