 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / Mac Programming / November 2007NSRunAlertPanelRelativeToWindow deprecation
I saw this message on my debug console about NSRunAlertPanelRelativeToWindow is being deprecated. The docs point to me to using a normal beginSheet etc., but two things stick out at me: 1. the run relative is done in-line allows code flow to continue 2. if there weren't a window yet [logic triggered before nib loaded] the sheet would appear as a separate window. While I can code around this and reproduce my own 'run relative' does anyone know the reason why this routine was deprecated? maybe I shouldn't munge my own?  Signature/los "I was a teenage net-random." > I saw this message on my debug console about > [quoted text clipped - 10 lines] > anyone know the reason why this routine was deprecated? maybe I > shouldn't munge my own? 1.) Think of this from the user's point of view: the alert comes up, your code is waiting for an answer, the user can't switch to another window in your app to get the data he needs to answer the question. Use sheets. 2.) Yes, the sheet API works that way: if the owning window is nil, you get an app modal alert box. >> I saw this message on my debug console about >> [quoted text clipped - 18 lines] > 2.) Yes, the sheet API works that way: if the owning window is nil, you > get an app modal alert box. But I like the API programming style in that the sheet is displayed and I wait for its end, in-line, rather than using a sheetDidEnd selector. Signature/los "I was a teenage net-random" ------------------------------------------------------------------------ Opinions expressed here are mine and not necessarily those of my employer! ------------------------------------------------------------------------ >> 1.) Think of this from the user's point of view: the alert comes up, >> your code is waiting for an answer, the user can't switch to another [quoted text clipped - 6 lines] > But I like the API programming style in that the sheet is displayed and > I wait for its end, in-line, rather than using a sheetDidEnd selector. Well, too bad. The right thing to use here is a sheet, and sheets simply cannot support that inline style of coding. (Not only does the API not support it, the *concept* does not support it; consider what happens when showing two sheets on two different windows, and closing them in something other than LIFO order.) SignatureMichael Ash Rogue Amoeba Software > >> 1.) Think of this from the user's point of view: the alert comes up, > >> your code is waiting for an answer, the user can't switch to another [quoted text clipped - 12 lines] > showing two sheets on two different windows, and closing them in something > other than LIFO order.) Technically, there is nothing conceptually impossible there -- if you use threads. By the time you pulled that off, thought, you'd be wishing you used sheetDidEnd directly instead. Ben SignatureIf this message helped you, consider buying an item from my wish list: <http://artins.org/ben/wishlist> I changed my name: <http://periodic-kingdom.org/People/NameChange.php> >> Well, too bad. The right thing to use here is a sheet, and sheets simply >> cannot support that inline style of coding. (Not only does the API not [quoted text clipped - 5 lines] > threads. By the time you pulled that off, thought, you'd be wishing you used > sheetDidEnd directly instead. I guess it depends on just how conceptual you get. I have written an inline sheet API using userland cooperative threading. It worked, but it turned out to be infeasible to save and restore all of the thread-specific Cocoa state such as autorelease pools and graphics contexts, so weird things happened when you used it. In the larger picture, the sort of implicit contract with the API is that threads don't happen without an explicit request, and that all GUI happens on a single thread. You will have to violate this model in some way with an inline sheet API, so that any code that could potentially be sitting on the stack when a sheet was invoked would suddenly need to be reentrant, even code that's many calls up the chain from the code that actually displays the sheet. A Cocoa-like API with a different threading model (something like the Be model of one thread per window would do it) could pull it off, but I don't think that Cocoa itself can accomodate it even in theory. SignatureMichael Ash Rogue Amoeba Software > Well, too bad. The right thing to use here is a sheet, and sheets simply > cannot support that inline style of coding. (Not only does the API not > support it, the *concept* does not support it; consider what happens when > showing two sheets on two different windows, and closing them in something > other than LIFO order.) boo hoo; ok, 'uncle' I'm convinced...;-) Signature/los "I was a teenage net-random." |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.