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?
Nope, the semaphore file is destroyed by the main program's printing class immediately after a value is retrieved from it. It is not recreated until the printing .exe is run again and generates a return value. 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. Thank you. I'd like to see it if you still want to send it after you read the rest of this message. <g> Rather than continuing to fight with this particular issue any longer, and given the fact that I have to disrupt the work of the users of the problem machines to test different scenarios, I've opted for another, better, work-around than the "Please wait..." messagebox. My base reports class, from which the problem report class is subclassed, always erases the detail table before recreating it for each new report. And the base class also retains a list of any tables created during a report run, and subclasses can call a base class method to loop through the list and erase the tables when the subclass is destroyed. So the base class code that erases the detail table immediately after printing is redundant, an artifact of my obsessiveness about cleaning up. I modified the base class method to accept a logical parameter that can prevent this erasure when called by a particular subclass. Instead, for this particular report only, the table will be erased either just prior to another report run, or when the subclass is destroyed (which happens when the parent form is closed). The result is that the problem on those strange machines goes away, and I don't have to have the "Please wait..." messagebox. That messagebox has to time-out eventually because I have an automatic shutdown module on this system, and it might do so waiting for the user to respond to the Windows generic printer dialog (if the user elected to display it, it's called by the printing .exe), in which case the table could get erased and the error would occur anyway. I still don't understand why this problem occurs, but if I had to bet I'd guess it was something to do with the particular (rather old) printer (Brother HL1440 B&W laser--a very good cheap laser printer, BTW, but no longer available; the substitute is HL2040, under $100 after rebate at Staples), its driver, and the time it takes to "wake" it up for a print job, in combination with the fact that this report has two pages and must render several images. Thanks to everybody for all your help on this. 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.
