Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Tioga Printer Module status reporting

Sorry about this mistake but I thought I better fix it to make things clear.

The line:
- Report the error to the printing system, making sure you are not in a call
to the [PMNotificationProc] and don't call it after this.

Should be:
- Report the error to the printing system, making sure you are not in a call
to the [PMJobStreamGetNextBandProc] and don't call it after this.

Again, sorry for any confusion.

Dan


-----Original Message-----
From: email@hidden
[mailto:email@hidden]On Behalf Of Daniel J.
McGillivray
Sent: Tuesday, March 02, 2004 12:41 PM
To: email@hidden
Subject: Tioga Printer Module status reporting


Hi All,

I know this is an old subject but we have taken a long look at the way we
report status and I'd like to get some input from Apple as to whether we are
missing something.

When canceling from a recoverable error sheet, the message seems to be
cached and displayed in the beginning of the next print job. It is cleared
when we report the first normal status. I believe this is a known Apple
issue. Is there a release scheduled to contain a fix?


I understand the recommended method for handling fatal errors to be:

- Report the error to the printing system, making sure you are not in a call
to the PMNotificationProc and don't call it after this.

- Break out of the printing loop, assuming your in PrintPage.

- Wait for CancelJob to be called, called on a separate thread.

- Call EndJob, or a clean up method from PrintPage.

Is this correct?
BTW, we return kPMCanceled from PrintPage in this case and the cancel case.
Is this correct?


When we report a fatal error we get the following behavior:
- The error sheet is displayed then removed automatically.
- The job is stopped and restarted automatically.

I have observed the following on OS 10.2.8 trying to figure out why:

Working with a fatal error that causes the PMIOWriteProc to fail:
After reporting the error to the printing system, if we "finish" before
CancelJob is called, the error sheet stays put until the user dismisses it.
By "finish" I mean call End Job, return from PrintPage, and return from the
call to EndJob made by the printing system. If we wait for CancelJob to be
called, we get the behavior described above. It seems like CancelJob is
doing something to cause this.

Working with a fatal error that causes the PMIOWriteProc to block:
This one is a little trickier. We can't close the I/O because the
PMIOCloseProc function doesn't return. Makes sense since the write is
blocked. If we don't close the I/O, it seems the printing system, or some
other component, doesn't like it and we get the wrong behavior described
above.

The declaration of the Close function in PMIOModule.h has the boolean
parameter abort. But the declaration of the PMIOCloseProcPtr in
PMPrinterModule.h does not have this parameter. Must be the printing system
is providing this parameter for a Tioga PM. It looks like the printing
system provides a value of true after CancelJob is called. This means the
workaround described for the PMIOWriteProc failure case won't work.

There seems to be a period of time after reporting a fatal error and before
CancelJob is called in which we can successfully close the I/O. BTW, this
also causes the write to return with an error which makes sense. It also
seems this period of time is too small and unpredictable to even think about
implementing a workaround for this problem.


Any feedback would be greatly appreciated. If this information is new, I
hope it will help you fix this problem and help others understand why it is
happening.


Thanks, Daniel McGillivray
Sr. Software Engineer
Vanteon Corporation
2851 Clover Street
Pittsford, NY 14534
www.vanteon.com
Office: (585) 248-0510 ext. 238
Fax: (585) 248-0537
_______________________________________________
printing mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/printing
Do not post admin requests to the list. They will be ignored.
_______________________________________________
printing mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/printing
Do not post admin requests to the list. They will be ignored.

References: 
 >Tioga Printer Module status reporting (From: "Daniel J. McGillivray" <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.