Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Variable not found when hitting print button
Message
From
18/02/2011 03:02:47
 
 
To
17/02/2011 13:44:30
General information
Forum:
Visual FoxPro
Category:
Reports & Report designer
Environment versions
Visual FoxPro:
VFP 8 SP1
Miscellaneous
Thread ID:
01499836
Message ID:
01500663
Views:
64
>I tend to think this isn't applicable because there are no "next lines."

Yes - but perhaps something similar happens inside the report engine ?
If this were vfp9, ReportPreview.App could be hacked gd&r

>There is a REPORT FORM PREVIEW and then the user hits a button in the toolbar (It first appeared on PRINT but it also happens with NEXT/LAST PAGE). It jumps to the CATCH block and shows that the work area has changed. No code (other than toolbar code - is there a way of finding that code and stepping through it???) runs.

As running under the debugger seems to cure it, I'd add a couple of DoEvents before calling the report, as events are handled differently when running under the debugger. If vfp8 already allows creating coverage logs in the runtime I'd set that - probably no info gain, as the error seems to be inside the untraceable report engine, but it might "fix" it due to similar running structure. It is a quick way to identify different vfp code paths as well.

Another idea: inside the report engine a line äquivalent to "Store eval(cInfo) to uvar" exists and is missing the mDot due to age. In your report table you have a column named cInfo, which masks the m.cInfo from the report and redirects to a missing variable. As the debugger "cures" it, something about the DS must also be involved for that idea to be true. Changing all column names (running a duplicate with minimal no. of altered column names) is the way to test it.

Even more work is creating special functions called during the report output - these could be used to log progress of calculation.

So checking if anything defined in the frx results in the behaviour is probably the only way to hack against it - did you try vfp9 to check if the error is happening there as well ? Might be more cost effective to port - speaking from the expirience of having to identify and code around some of vfp's internal errors. In the long run the cost for checking the new runtime NOW will be offset against all still answering fox heads in the future probably knowing this release best ;-)

sympathies...

thomas
Previous
Reply
Map
View

Click here to load this message in the networking platform