Hmmmmm... interesting. Just a couple of thoughts 1. Is it possible the reporting class is grabbing the semaphore file before it printing.exe has populated it? 2. As a debugging aid I have a method/function that writes a trace file (FWRITE to a plain text file) with whatever debugging information may be useful at that point. You might sprinkle something like this all around in your reporting class and printing.exe to try and get a better idea what's happening. If you're interested I can send you a copy of the function. Regards, Scott Ramey BDS Software
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Ken Dibble > Sent: Tuesday, April 17, 2007 12:18 PM > To: [email protected] > Subject: RE: Printing Synchronization Problem > > > >Is there any particular reason you are only checking for a non-zero > return > >value? Are there other values, some of which may indicate a problem? > > > Thanks, Scott. > > Non-zero just means the printing process should have finished, one way or > another, since that's the only way it should be possible for that value to > be non-zero. > > 1 indicates success. There are three possible negative values that the > separate printing .exe can generate before the REPORT FORM... command can > run: > > - 1 The printing .exe couldn't find the job information table (the one > that > contains the REPORT FORM .... command to be executed). > -2 The printing .exe found the job info table but couldn't open it. > -3 The printing .exe opened the job info table but couldn't retrieve a > command from it. > > If any of those values is generated, the REPORT FORM... command is not > issued, but the printing .exe will still create the semaphore table with > the value and then terminate. Since the VFP Error 1 occurs on the REPORT > FORM... command, these situations aren't in play. > > - 4 User cancelled printing > > I use the ReportDone()/WasPrinted technique from Cathy Pountney's book to > generate this value if the user cancelled printing. This value gets > generated by the printing .exe after REPORT FORM ... runs, but in the > scenarios where the problem occurs, the user hasn't cancelled printing. > > The value we're talking about gets returned to the reporting class from > the > main program's printing class. That class, in addition to passing on a > value from the separate printing .exe's semaphore file, can return other > negative values indicating a problem in itself. > > Whether or not the returned value indicates success, the reporting class > cleans up by itself by erasing the temporary tables once it has that > value. > > Then, if the returned value isn't 1 or -4, the report class requests a > "translation" error message from the printing object for the value and > asks > its parent form to display the message via a MESSAGEBOX(). > > When the problem I'm describing occurs, the value returned from the > printing class is -5, which indicates the printing class did not retrieve > a > value from the semaphore file. This is consistent with the error occurring > in the .exe on the REPORT FORM ... line, since in that case the .exe's > error-handling/logging procedure is triggered and control never returns to > the code that generates the semaphore file. It also implies that my code, > including Tools.dll, is working correctly, since execution in the > reporting > class doesn't proceed until this value is returned. > > Since the printing program is generic, I don't attempt to find specific > temporary report header or detail tables in my tests in that program. The > report .frx does test for the presence of, and ability to open, those > tables in BeforeOpenTables() and will return .F. if those tests fail. > While > debugging this, I put MESSAGEBOX() calls in this BeforeOpenTables() method > that should have been triggered if the header or detail tables were not > found. They did not run, which implies to me that the REPORT FORM ... > command somehow detected the missing table before the .frx > BeforeOpenTables() event/method ran. > > Thanks again. > > Ken Dibble > www.stic-cil.org > > > > > > > > [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.
