I was actually wondering the same thing.
What is the reasoning behind a separate printing
program?
--- John Weller <[EMAIL PROTECTED]> wrote:
> 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.
