I would double check the "problem machines" and get rid of the "TMP" and
"TEMP" User Environmental variables on those machines.... see if that
helps. We've had problems with the MS default temp folders being placed
way out in the user's profile... We prefer leaving them to the default
system temp folder C:\Windows\Temp\...
something might be happening there with file not found or something...
Good luck.
Philip
Ken Dibble wrote:
> 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
>
>
>
>
_______________________________________________
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.
