General information
Category:
Coding, syntax & commands
>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
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only