This seems a very complex method of printing a report. Why not use cursors
for your report tables and call the REPORT FORM from within the main exe? I
appreciate that you have probably simplified the scenario for the [post and
that there are probably other, very good, reasons why you are doing it this
way. If you are using the printing exe in several apps then perhaps you
should be making it a class?
{I know, it's great when you ask for help and someone says - 'I wouldn't
have done it that way in the first place' <g> }
John Weller
01380 723235
07976 393631
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Ken Dibble
> Sent: 15 April 2007 16:23
> To: [EMAIL PROTECTED]
> Subject: Printing Synchronization Problem
>
>
> 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
>
>
>
>
[excessive quoting removed by server]
_______________________________________________
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.
