FROM : Ali Ozer
DATE : Sun Apr 20 00:36:41 2008
>> "In rare cases, you may want to display a caution icon in your
>> alert, badged with the application icon as shown in Figure 14-48. A
>> badged alert is appropriate only if the user is performing a task,
>> such as installing software, and a possible side effect of that
>> task would be the inadvertent destruction of data. Don’t use a
>> caution icon for tasks whose only purpose is to overwrite or remove
>> data, such as Save or Empty Trash; too-frequent use of the caution
>> icon dilutes its significance."
>
> Yet presentError: *always* chooses to use a badged caution icon,
> AFAICT, even though there's no good reason to assume that an error
> in general implies the possible "inadvertent destruction of data".
> For example, NSDocumentController reports (via presentError:, I
> assume) a failure to create or open a document with a caution icon,
> and in neither case is it likely that data destruction is imminent.
Yes, it would be good to be able to easily customize the badge on the
alert. I don't think there is a straightforward way to do this.
>> "The alert displays information found in the NSError object
>> anError; this information can include error description, recovery
>> suggestion, failure reason, and button titles (all localized)."
>
> In fact, AFAICT the failure reason is never included in the alert --
> the secondary (smaller) text always comes from the recovery
> suggestion and the failure reason is ignored.
Actually, the failure and the reason are both included in the default
presentError: call, assuming the error has them. For instance, trying
to open a read-protected file with NSData will result in:
Bold text: The file “foo.txt” could not be opened because you do not
have appropriate access privileges.
Smaller text: To view or change access privileges, select the item in
Finder and choose File > Get Info.
If you call individual methods on that NSError, you will see:
localizedDescription: The file “foo.txt” could not be opened because
you do not have appropriate access privileges.
localizedFailureReason: You do not have appropriate access privileges.
localizedRecoverySuggestion: To view or change access privileges,
select the item in Finder and choose File > Get Info.
> (3) According to the NSResponder class reference, a responder passes
> presentError to the next error responder and:
>
>> "if there is no next responder, it passes the error object to
>> NSApp, which displays a document-modal error alert"
>
> I had hoped this meant that NSApp cleverly displayed the error as a
> sheet on the document window and waited for it to be dismissed. In
> fact, if you send presentError: to a NSDocument you get an
> application-modal alert.
Actually, the comment for presentError: says "Present an error alert
to the user, as an application-modal panel"; it's
presentError:modalForWindow:delegate:didPresentSelector:contextInfo:
that puts up a doc-modal panel.
Ali
DATE : Sun Apr 20 00:36:41 2008
>> "In rare cases, you may want to display a caution icon in your
>> alert, badged with the application icon as shown in Figure 14-48. A
>> badged alert is appropriate only if the user is performing a task,
>> such as installing software, and a possible side effect of that
>> task would be the inadvertent destruction of data. Don’t use a
>> caution icon for tasks whose only purpose is to overwrite or remove
>> data, such as Save or Empty Trash; too-frequent use of the caution
>> icon dilutes its significance."
>
> Yet presentError: *always* chooses to use a badged caution icon,
> AFAICT, even though there's no good reason to assume that an error
> in general implies the possible "inadvertent destruction of data".
> For example, NSDocumentController reports (via presentError:, I
> assume) a failure to create or open a document with a caution icon,
> and in neither case is it likely that data destruction is imminent.
Yes, it would be good to be able to easily customize the badge on the
alert. I don't think there is a straightforward way to do this.
>> "The alert displays information found in the NSError object
>> anError; this information can include error description, recovery
>> suggestion, failure reason, and button titles (all localized)."
>
> In fact, AFAICT the failure reason is never included in the alert --
> the secondary (smaller) text always comes from the recovery
> suggestion and the failure reason is ignored.
Actually, the failure and the reason are both included in the default
presentError: call, assuming the error has them. For instance, trying
to open a read-protected file with NSData will result in:
Bold text: The file “foo.txt” could not be opened because you do not
have appropriate access privileges.
Smaller text: To view or change access privileges, select the item in
Finder and choose File > Get Info.
If you call individual methods on that NSError, you will see:
localizedDescription: The file “foo.txt” could not be opened because
you do not have appropriate access privileges.
localizedFailureReason: You do not have appropriate access privileges.
localizedRecoverySuggestion: To view or change access privileges,
select the item in Finder and choose File > Get Info.
> (3) According to the NSResponder class reference, a responder passes
> presentError to the next error responder and:
>
>> "if there is no next responder, it passes the error object to
>> NSApp, which displays a document-modal error alert"
>
> I had hoped this meant that NSApp cleverly displayed the error as a
> sheet on the document window and waited for it to be dismissed. In
> fact, if you send presentError: to a NSDocument you get an
> application-modal alert.
Actually, the comment for presentError: says "Present an error alert
to the user, as an application-modal panel"; it's
presentError:modalForWindow:delegate:didPresentSelector:contextInfo:
that puts up a doc-modal panel.
Ali
| Related mails | Author | Date |
|---|---|---|
| Quincey Morris | Apr 19, 21:47 | |
| Jerry Krinock | Apr 19, 22:46 | |
| Ali Ozer | Apr 20, 00:36 | |
| Quincey Morris | Apr 20, 03:18 |






Cocoa mail archive

