Cocoa newbie -- help with multiple windows

[Larry Fransson]

In article
<jamalbspambegone-BD6F68.18380106082003@newssvr13-ext.news.prodigy.com>,
Jamal Bernhard <jamalbspambegone@pacbell.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]

[Jon H]

On Thu, 7 Aug 2003 16:48:44 -0400, Jamal Bernhard wrote
(in message <1060289263.963031@sj-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.

[Eric Pepke]

Jamal Bernhard <jamalbspambegone@pacbell.goawayspam.net> wrote in message news:<jamalbspambegone-BD6F68.18380106082003@newssvr13-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.

[Jamal Bernhard]

[email]epepke@acm.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]

[email]epepke@acm.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 documented to avoid a line
> or two of code is usally going to come back and bite you later.

Gotcha -- thanks.

[Michael J Ash]

On Sat, 9 Aug 2003, Jamal Bernhard wrote:

> [email]epepke@acm.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:mail@mikeash.com>

[Michael J Ash]

On Sat, 9 Aug 2003, Jamal Bernhard wrote:

> [email]epepke@acm.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 documented 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 documented along with AppKit's
docs. See NSBundle Additions in the AppKit docs for this method's
documentation. 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:mail@mikeash.com>

[Chris Hanson]

In article <ef37f531.0308090404.38fed9aa@posting.google.com >, Eric
Pepke <epepke@acm.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 documented to avoid a line
> or two of code is usally going to come back and bite you later.

-[NSBundle loadNibNamed:] is fully documented 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]cmh@bDistributed.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]cmh@mac.com[/email]

[Jamal Bernhard]

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]

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 replicate 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 screwed. :-)

> 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!

[Eric Pepke]

Jamal Bernhard <jamalb.spambegone@pacbell.goodbyespam.net> wrote in message news:<1060808612.679293@sj-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]

Jamal Bernhard <jamalb.spambegone@pacbell.goodbyespam.net> wrote in message news:<1060902111.380522@sj-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?