>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 _______________________________________________ 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.
