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: What do we want in Carbon? (was Modern C++)



On 11/7/03 1:04 PM, Pete Gontier didst favor us with:

> circa 11/6/03 4:03 PM, Laurence Harris <email@hidden> wrote:
>
>>> For example, do you think it's a safe assumption that the DialogRef passed
>>> to
>>> RunStandardAlert was created by CreateStandardAlert? Seems reasonable,
>>> doesn't it? You'd be wrong. Some apps pass non-StandardAlert DialogRefs to
>>> RunStandardAlert. We had to work around that.
>
>> I wouldn't have spent time working around that beyond teaching
>> RunStandardAlert to return an error code if passed a non-StandardAlert
>> DialogRef. ;-)
>
> Yes, I saw the wink and the smile, but seriously, Apple engineers do not
> have this luxury. If the offending apps are sufficiently popular, Apple
> can't afford to break them just for the sake of correctness.

This would not be breaking any applications as I understand it. According to
Eric, they had to modify RunStandardAlert to *fix* the offending
applications. I don't think it's in anyone's best interest for Apple's
overworked engineers to have to modify code in the OS to accommodate
incorrectly written code in *any* third party application.

From Dialogs.h:

* Discussion:
* RunStandardAlert displays and runs an alert created by
* CreateStandardAlert. It handles all user interaction with the
* alert. After the user has dismissed the alert, RunStandardAlert
* destroys the alert dialog; the DialogRef will be invalid after
* RunStandardAlert returns.
*
* NOTE: DO NOT call this function for a dialog that was not created
* with CreateStandardAlert! You will sorely regret it, I promise
* you.

A while back when someone posted a question about the fact that a menu item
indent of -1 indented menu items to the left in Jaguar, but made the text
disappear in Panther, the official response was: "That parameter is a
UInt32. Don't use -1."

> There are all sorts of issues Apple geeks must endure of which the rest of us
> remain blissfully unaware.

No doubt. But I've found over the years that my code survives new releases
of the OS very well if don't rely on undocumented assumptions unless there
is absolutely no alternative.

Larry
_______________________________________________
carbon-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/carbon-development
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: What do we want in Carbon? (was Modern C++) (From: Pete Gontier <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.