>>Bob,
>>
>
>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

Bob,

If you change SET PROCEDURE to SET LIBRARY you drop your global routine in the search order to below the subroutines in the calling chain. I have no idea if this would break other code, but it's a thought.

The order is:

PROCs in the current module
PROCs in SET PROCEDURE file
PROCs in modules in the calling chain
PROCs in SET LIBRARY
External Files (APP, FXP, EXE, PRG)

Randy