Professional Web Applications Themes

Cocoa newbie -- help with multiple windows - Mac Programming

In article <jamalbspambegone-BD6F68.18380106082003newssvr13-ext.news.prodigy.com>, Jamal Bernhard <jamalbspambegonepacbell.goawayspam.net> wrote: > When I need to access preference values from other class > methods, is the overhead of retrieving preference values great enough > that I should create accessor methods in the preferences controller > class to get those values directly from the class instance? Reading and writing preferences happens more quickly than you can think about it. It's not worth the extra effort. -- Larry Fransson Aviation software for Mac OS X! [url]http://www.subcritical.com[/url]...

  1. #1

    Default Re: Cocoa newbie -- help with multiple windows

    In article
    <jamalbspambegone-BD6F68.18380106082003newssvr13-ext.news.prodigy.com>,
    Jamal Bernhard <jamalbspambegonepacbell.goawayspam.net> wrote:
    > When I need to access preference values from other class
    > methods, is the overhead of retrieving preference values great enough
    > that I should create accessor methods in the preferences controller
    > class to get those values directly from the class instance?
    Reading and writing preferences happens more quickly than you can think
    about it. It's not worth the extra effort.

    --
    Larry Fransson
    Aviation software for Mac OS X!
    [url]http://www.subcritical.com[/url]
    Larry Fransson Guest

  2. #2

    Default Re: Cocoa newbie -- help with multiple windows

    On Thu, 7 Aug 2003 16:48:44 -0400, Jamal Bernhard wrote
    (in message <1060289263.963031sj-nntpcache-5>):
    > Larry Fransson wrote:
    >
    >>> When I need to access preference values from other class
    >>> methods, is the overhead of retrieving preference values great enough
    >>> that I should create accessor methods in the preferences controller
    >>> class to get those values directly from the class instance?
    >>
    >> Reading and writing preferences happens more quickly than you can think
    >> about it. It's not worth the extra effort.
    >
    > Cool -- thanks. Coming from device-driver territory, I'm trained to
    > think about overhead. :-)
    If it's something you hit often, you obviously want to
    cache the value.

    You don't want to do the preferences access in a for() loop condition
    clause.

    It's not *that* fast.

    Jon H Guest

  3. #3

    Default Re: Cocoa newbie -- help with multiple windows

    Jamal Bernhard <jamalbspambegonepacbell.goawayspam.net> wrote in message news:<jamalbspambegone-BD6F68.18380106082003newssvr13-ext.news.prodigy.com>...
    > 1.
    >
    > I don't want the user to be able to make the original window active
    > while the prefs window is displayed. Seems simple but I can't figure out
    > how to do it.
    Look at NSApplication's runModalForWindow method.

    But first, think very hard about whether you really need to do this.
    Eric Pepke Guest

  4. #4

    Default Re: Cocoa newbie -- help with multiple windows

    [email]epepkeacm.org[/email] (Eric Pepke) wrote:
    > > I don't want the user to be able to make the original window active
    > > while the prefs window is displayed. Seems simple but I can't figure out
    > > how to do it.
    >
    > Look at NSApplication's runModalForWindow method.
    >
    > But first, think very hard about whether you really need to do this.
    Thanks. I did think about this for awhile. It seems this is a fairly
    common "feature" in applications -- if the user brings up the prefs
    window then they must finish with and close the prefs window before
    going back to work, and it doesn't seem to me to cause the user much
    strife...Do you feel this goes against good UI guidelines?
    Jamal Bernhard Guest

  5. #5

    Default Re: Cocoa newbie -- help with multiple windows

    [email]epepkeacm.org[/email] (Eric Pepke) wrote:
    > >I see different approaches being
    > > used. In addition to a couple of inline questions below, I'm trying to
    > > figure out in general what each approach buys you and whether one is
    > > more/less useful.
    >
    > TIMTOWTDI
    Wow, sorry, I've been on usenet for awhile but never seen this one...
    :-)

    > > This approach doesn't use a NSWindowController at all:
    > >
    > > - (IBAction)showPrefs:(id)sender
    > > {
    > > if (!prefsPanel)
    > > {
    > > [NSBundle loadNibNamed:"PrefsPanel" owner:self];
    > > }
    > >
    > > [prefsPanel makeKeyAndOrderFront: nil];
    > > }
    > >
    > > Does this approach have limitations, since it seems to be simpler?
    >
    > Well, it seems incomplete: what sets the prefsPanel variable anyway?
    I believe it gets set becuase of the connection made between the
    PrefsPanel nib and File's Owner in IB. File's Owner is set to the
    Controller class that implements showPrefs above (and that has
    prefsPanel as an instance variable). My understanding is that when the
    nib is loaded, this connection is made automatically.
    > But I would shy away from this one simply because, when I bring up
    > the NSBundle page, loadNibNamed is not listed. Looking deeper,
    > of course, it is implemented. However, in my experience, trying to be
    > clever and doing something not overtly doented to avoid a line
    > or two of code is usally going to come back and bite you later.
    Gotcha -- thanks.
    Jamal Bernhard Guest

  6. #6

    Default Re: Cocoa newbie -- help with multiple windows

    On Sat, 9 Aug 2003, Jamal Bernhard wrote:
    > [email]epepkeacm.org[/email] (Eric Pepke) wrote:
    >
    > > > I don't want the user to be able to make the original window active
    > > > while the prefs window is displayed. Seems simple but I can't figure out
    > > > how to do it.
    > >
    > > Look at NSApplication's runModalForWindow method.
    > >
    > > But first, think very hard about whether you really need to do this.
    >
    > Thanks. I did think about this for awhile. It seems this is a fairly
    > common "feature" in applications -- if the user brings up the prefs
    > window then they must finish with and close the prefs window before
    > going back to work, and it doesn't seem to me to cause the user much
    > strife...Do you feel this goes against good UI guidelines?
    This used to be a common feature, but look at the preference windows in a
    few random Mac OS X apps. You'll find that most, if not all, of them are
    modeless dialogs. If you think about it for a moment, it makes a lot more
    sense that way. Modal dialogs are for things that absolutely must be
    completed before you can use the rest of the program. Very few things fit
    into this category. A critical alert might. Save windows used to, but
    Apple no longer recommends this, thus the existance of sheets. There is no
    good reason to force the user to complete the preferences dialog before
    using the rest of the program. If this causes problems with your
    preferences architecture (not registering changes until the user clicks OK
    or something) then you should fix your architecture, not force the user to
    conform to it.

    --
    "From now on, we live in a world where man has walked on the moon.
    And it's not a miracle, we just decided to go." -- Jim Lovell

    Mike Ash - <http://www.mikeash.com/>, <mailto:mailmikeash.com>

    Michael J Ash Guest

  7. #7

    Default Re: Cocoa newbie -- help with multiple windows

    On Sat, 9 Aug 2003, Jamal Bernhard wrote:
    > [email]epepkeacm.org[/email] (Eric Pepke) wrote:
    >
    > > > This approach doesn't use a NSWindowController at all:
    > > >
    > > > - (IBAction)showPrefs:(id)sender
    > > > {
    > > > if (!prefsPanel)
    > > > {
    > > > [NSBundle loadNibNamed:"PrefsPanel" owner:self];
    > > > }
    > > >
    > > > [prefsPanel makeKeyAndOrderFront: nil];
    > > > }
    > > >
    > > > Does this approach have limitations, since it seems to be simpler?
    > >
    > > Well, it seems incomplete: what sets the prefsPanel variable anyway?
    >
    > I believe it gets set becuase of the connection made between the
    > PrefsPanel nib and File's Owner in IB. File's Owner is set to the
    > Controller class that implements showPrefs above (and that has
    > prefsPanel as an instance variable). My understanding is that when the
    > nib is loaded, this connection is made automatically.
    This is absolutely correct. It's probably a slightly better idea to use an
    NSWindowController, but your technique works perfectly well, and is
    perfectly acceptable.
    > > But I would shy away from this one simply because, when I bring up
    > > the NSBundle page, loadNibNamed is not listed. Looking deeper,
    > > of course, it is implemented. However, in my experience, trying to be
    > > clever and doing something not overtly doented to avoid a line
    > > or two of code is usally going to come back and bite you later.
    >
    > Gotcha -- thanks.
    This is wrong. Type "loadNibNamed" into your indexed PB Cocoa project and
    option-double-click it to read the docs. The grandparent poster didn't
    find this in NSBundle's docs because it's not in NSBundle's docs. Some
    classes, like NSBundle and NSAttributedString have separate methods in
    AppKit using categories, and these are doented along with AppKit's
    docs. See NSBundle Additions in the AppKit docs for this method's
    doentation. This will not come back and bite you, it is a large,
    important part of nib loading.

    Bitten by my news server again, I don't have enough "new" text.

    Let's see if this is enough.

    --
    "From now on, we live in a world where man has walked on the moon.
    And it's not a miracle, we just decided to go." -- Jim Lovell

    Mike Ash - <http://www.mikeash.com/>, <mailto:mailmikeash.com>

    Michael J Ash Guest

  8. #8

    Default Re: Cocoa newbie -- help with multiple windows

    In article <ef37f531.0308090404.38fed9aaposting.google.com >, Eric
    Pepke <epepkeacm.org> wrote:
    > Well, it seems incomplete: what sets the prefsPanel variable anyway?
    prefsPanel is probably an outlet that's set when the PrefsPanel nib is
    loaded.
    > But I would shy away from this one simply because, when I bring up
    > the NSBundle page, loadNibNamed is not listed. Looking deeper,
    > of course, it is implemented. However, in my experience, trying to be
    > clever and doing something not overtly doented to avoid a line
    > or two of code is usally going to come back and bite you later.
    -[NSBundle loadNibNamed:] is fully doented and supported. It's
    added to NSBundle in a category in the AppKit's NSBundle Additions,
    rather than in the basic NSBundle class in the FoundationKit.

    -- Chris

    --
    Chris Hanson, bDistributed.com, Inc. | Email: [email]cmhbDistributed.com[/email]
    Custom Application Development | Phone: +1-847-372-3955
    [url]http://bdistributed.com/[/url] | Fax: +1-847-589-3738
    [url]http://bdistributed.com/Articles/[/url] | Personal Email: [email]cmhmac.com[/email]
    Chris Hanson Guest

  9. #9

    Default Re: Cocoa newbie -- help with multiple windows

    Michael J Ash wrote:
    >>Thanks. I did think about this for awhile. It seems this is a fairly
    >>common "feature" in applications -- if the user brings up the prefs
    >>window then they must finish with and close the prefs window before
    >>going back to work, and it doesn't seem to me to cause the user much
    >>strife...Do you feel this goes against good UI guidelines?
    >
    > This used to be a common feature, but look at the preference windows in a
    > few random Mac OS X apps. You'll find that most, if not all, of them are
    > modeless dialogs. If you think about it for a moment, it makes a lot more
    > sense that way. Modal dialogs are for things that absolutely must be
    > completed before you can use the rest of the program. Very few things fit
    > into this category. A critical alert might. Save windows used to, but
    > Apple no longer recommends this, thus the existance of sheets. There is no
    > good reason to force the user to complete the preferences dialog before
    > using the rest of the program. If this causes problems with your
    > preferences architecture (not registering changes until the user clicks OK
    > or something) then you should fix your architecture, not force the user to
    > conform to it.
    The issue is not with my architecture, but with how the app should
    behave. In this case, the app is a simple timer that plays a sound at
    either a fixed or random time interval (to be set by the user in the
    prefs window). Since the prefs are used to start a new timer, it seemed
    like a better idea to wait until the user was done changing prefs before
    starting said timer. Of course, if the user brings up the prefs window
    and changes one of the bounds, I *could* just restart the timer while
    leaving the prefs window open, and then do it again when they change the
    next bound. But this is such a simple app it didn't seem necessary.

    Thanks for the input. I'm using this program as a Cocoa learning
    experience as much as anything else, so I'll probably implement the
    prefs window as non-modal, if for no other reason than just to do it! :-)

    Jamal Bernhard Guest

  10. #10

    Default Re: Cocoa newbie -- help with multiple windows

    Chris Hanson wrote:
    > That said, you should avoid modal windows when possible. The better
    > thing would be to have a preferences window where changes are reflected
    > immediately.
    Yes, that seems to be the common stance. Given that this is a very
    simple app that runs a timer based on the user prefs, I figured it was
    okay to make the user close the prefs window before reloading the timer.
    But I will probably make it non-modal.

    >>Does this approach have limitations, since it seems to be simpler?
    >
    > The main limitation is that you don't have all of the support machinery
    > NSWindowController gives you. It's not a *lot* but you'll still wind
    > up creating most of it yourself. Better to just use NSWindowController
    > in the first place.
    Makes sense. I'm still in the early stages of learning so I haven't yet
    figured out what NSWindowController buys you in terms of "support
    machinery". For this particular application it's doesn't seem to be
    needed, but I'll probably use it to force myself to learn more about it.
    :-)

    > In particular, one useful pattern is to use -awakeFromNib to finish
    > configuring the controls in your window, and to use -windowDidLoad to
    > populate them with data. In fancy words, you use -awakeFromNib to
    > finish the mechanical set-up of the window that was begin in the nib
    > file, but you use -windowDidLoad to finish the semantic set-up fo the
    > window by populating its controls with data. You can te this
    > fairly easily without using NSWindowController, but you can do
    > something else with that 5 minutes if you just use NSWindowController.
    > :)
    Ahh, okay. I didn't do this in my simple app because every time the
    window is opened it should contain the same data it did when it was
    closed, so I only need to initialize window data the first time. I'm
    using -awakeFromNib to initialize data in the window, and it's working
    just fine. However, if I needed to populate any controls with data on
    subsequent window opens, I guess I'd be ed. :-)

    > One other thing NSWindowController buys you: When an NSWindowController
    > is released, it will release all top-level instantiated objects in a
    > nib it loaded itself. If you don't use NSWindowController, you have to
    > do this yourself to avoid memory leaks.
    Ahh...cool.


    Thanks for the help!

    Jamal Bernhard Guest

  11. #11

    Default Re: Cocoa newbie -- help with multiple windows

    Jamal Bernhard <jamalb.spambegonepacbell.goodbyespam.net> wrote in message news:<1060808612.679293sj-nntpcache-5>...
    > The issue is not with my architecture, but with how the app should
    > behave. In this case, the app is a simple timer that plays a sound at
    > either a fixed or random time interval (to be set by the user in the
    > prefs window). Since the prefs are used to start a new timer, it seemed
    > like a better idea to wait until the user was done changing prefs before
    > starting said timer. Of course, if the user brings up the prefs window
    > and changes one of the bounds, I *could* just restart the timer while
    > leaving the prefs window open, and then do it again when they change the
    > next bound. But this is such a simple app it didn't seem necessary.
    I don't think that's the thing that Michael or I is trying to say. You can
    certainly have an OK button on the window or something and make the
    change work like that.

    But what value is there in preventing the user from doing something
    else while the window is up?

    People did it back in the past simply because it was so much easier to
    put up a modal dialog box than a modeless dialog box. (The original
    Mac API didn't really even have the concept of a modeless dialog box.)
    However, that is no longer the case; it's easier to produce a modeless
    window than a modal one.

    There are only rare instances when I think it's right to have a modal
    dialog box.
    Eric Pepke Guest

  12. #12

    Default Re: Cocoa newbie -- help with multiple windows

    Jamal Bernhard <jamalb.spambegonepacbell.goodbyespam.net> wrote in message news:<1060902111.380522sj-nntpcache-5>...
    > Yes, I see your point completely. This app just happens to be a bad
    > example because aside from the preferences window there is nothing to
    > prevent the user from doing...
    But there are things the user might want to do, and they consist of everything
    in the menu bar that don't have anything to do with your program. For all
    you know, the user might have some sort of application that puts a little
    menu to the right of any standard menu, like the Character Palette does.
    Maybe this is, say, a calendar, and he needs to open it up to find the time
    to set the timer for. Or whatever.

    Furthermore, the most important feature of *any* program is Quit, and that
    at least should always be accessible.

    IMO, I have seen only two instances where modal dialogs are approprate:
    1) Cases where an operation that requires user interaction must be forced
    to be atomic.
    2) Cases where the user must be made aware of a condition immediately,
    lest he and/or she do something dangerous in ignorance.

    Both are generally symptoms of poor design. They may, at times, be
    unavoidable poor design--dealing with old, crufty, code, deadline
    pressures, interim fixes--but they're still generally poor. There are
    exceptions, but they are few and far between, and often a sheet
    (window-modal versus application-modal) is a better approach.

    For example, I would make a print dialog a sheet. Sheets are distinctive
    and attention-grabbing (so much so that many consider the animation
    annoying) and beg immediate interaction. However, the only reason that
    I would do that is because without that, a lot of users are going to get
    up, run to the printer, wait for the other person's 40-page job to finish,
    and then be disappointed when it doesn't. This is more likely to happen
    with a nice little unobtrusive modeless window than with a sheet.

    But these are rare cases.

    This probably sounds preachy, but since you're in the process of learning
    and have complete control over the code you write, why not get it right
    the first time?
    Eric Pepke Guest

Similar Threads

  1. NEWBIE : Help !!! Flash menu opens multiple instances
    By Freelander in forum Macromedia Flash
    Replies: 1
    Last Post: January 20th, 06:05 AM
  2. Multiple Variables set in a cookie? NEWBIE
    By GH HM in forum PHP Development
    Replies: 0
    Last Post: October 20th, 05:13 PM
  3. newbie cocoa file reading/writing files
    By Richard Humiston in forum Mac Programming
    Replies: 1
    Last Post: July 21st, 02:42 PM
  4. multiple doent and window types in cocoa
    By matt neuburg in forum Mac Programming
    Replies: 0
    Last Post: July 21st, 02:35 PM
  5. Cocoa and semi-transparent rounded windows
    By Ronny Salomonsen in forum Mac Programming
    Replies: 3
    Last Post: July 16th, 01:53 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139