After another good bit of testing, I have a proposed explanation of the
printing crashing, a new revelation, and a question or two:
1. Populating a printersetup using ps.setupstring = SetupString randomly
fails silently (and fails much more often on HP and network printers)
I've failed to work around this bug using every trick I've found mentioned
in the list archives -- a delay between creation and use of ps, a delay
between creation and setupstring assignment, and checking/assigning encoding
to both the setup string and ps.setupstring)
2. Accessing any property of ps after the assignment of the sting instantly
crashes your Windows application.
3. If you simply use a corrupted printersetup to open a print job,
g= OpenPrinter(ps) or OpenPrinterDiilog(ps), you make things a lot worse:
A. the Windows program hangs rather than crashes, Dr Watson sometimes
pops up.
B. A force quit of your app often fails to close your app completely as
Dr. Watson often stays running indefinitely (as seen in the processes of the
Task Manager).
C. A restart of your application with a mutex will often fail (because
of B above), telling you it is already running.
4. If you are successful in getting your app restarted, a fresh pagesetup
now will nearly always instantly fail because your printer is now hosed.
A. A restart of the computer sometimes fixes things, sometimes not.
B. A restart AND switching to a different printer in the pagesetup
dialog always clears the corrupted printer and therfore enables a good
pagesetup. Switching back to the original printer then works fine until the
next random corruption of the printersetup when assigning the string (see
#1).
Today's Revelation:
The printer hassles and app hangs (3-4) are SOLVED if we always test a
property of printersetup ps BEFORE using it to try to print (always do step
2 before printing).
The app will crash when you test a corrupted PS, but it will crash clean and
not hose your selected printer, hang Dr. Watson, etc. that starts a vicious
cycle with the application misbehaving.
Question:
It appears that if we could somehow evaluate ps without crashing (after
assigning the setup string by before using it to print), we would have a
solid workaround. Any ideas how to do this?
I've tried checking every property (always crashes when ps is corrupt),
checked isa (it passes even when ps is corrupt).
Any comments or ideas are really appreciated,
Keith DeLong
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
