Here's one I hope will be interesting.
I use a separate .exe to print reports. My main program creates a couple of
temporary report tables--a header table and a details table. Neither is
very big; the details table has maybe a couple dozen rows. But the report
takes (by design) two pages. After the report is printed, the main program
erases those tables. I've got several measures in place to ensure that my
main program doesn't do anything until the report data is safely in the
printer memory. But on some machines this doesn't work. The details table
gets erased before the report gets run, producing VFP Error 1 ("file does
not exist") when the REPORT FORM ... command is run in the separate
printing program. Details follow:
When the report tables have been created, my main program report class
hands the job off to my printing class, also in the main program. The
report class then runs a DO WHILE... loop waiting for a return value from
the report class. Only when the return value is something other than 0
should execution resume in the report class.
The main program printing class creates its own temporary table that
contains the printing command to be executed by the separate printing .exe.
It then calls the free third-party Tools.dll utility's RunAndWait() method
to start the separate printing .exe. This utility is supposed to wait until
the .exe finishes running before returning a success/failure value.
The printing .exe gets the command out of the print command table and runs
it. During this process, several tests are run and various return code
values will be generated if something goes wrong. Once a return code value
signaling success or failure is established, the printing .exe creates a
semaphore .txt file containing that code, and terminates. There's a FOR ...
ENDFOR loop after the REPORT FORM ... command runs to allow time for the
printer to get started before the printing .exe terminates.
At this point the main program printing .exe should get a return value from
Tools.RunAndWait() and move on. It then retrieves the value stored to the
semaphore file, erases that file, and returns the value back to the report
class.
The report class has been running a DO WHILE ... loop waiting for that
value to be non-zero. When that happens, the report class then erases the
temporary report header and detail tables.
This usually works just fine. This chain of events is used for all types of
printing in my system, and it only has a problem with this one particular
two-page report.
However, on some machines, the report class gets its return value
populated, and therefore erases the tables, before the REPORT FORM ...
command in the separate printing .exe fully completes. The report class
erases the detail table first, then the header table. I can see, at the
time the error occurs, that the header table is still there but the detail
table is gone.
My work-around is to put a MESSAGEBOX("Please wait for printing to
finish.") call ahead of the ERASE commands for this particular report. I
really don't like this, though, and it seems to me that my system should
work without doing that. How the heck can that DO WHILE ... loop terminate
with a received value while the separate .exe is still running and,
therefore, should not have issued that value?
This occurs only on some machines. It doesn't appear to be a
processor-speed or OS issue; processor speeds and OSes are the same on
machines where it works and where it doesn't. Printers are different,
though, in some but not all cases.
Any thoughts?
TIA,
Ken Dibble
www.stic-cil.org
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 269.4.0/760 - Release Date: 4/13/2007 8:04 PM
_______________________________________________
Post Messages to: [EMAIL PROTECTED]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
