NSTextField -- question about when actions are sent

[Jamal Bernhard]

I have a prefs window with a few NSTextFields. I am noticing two things:

1. Every time the prefs window is opened, the NSTextField that is the
initial responder immediately sends its action to the target.

2. If I edit data in one of the text fields but don't deselect the text
field (via tab, return, clicking on another control, etc) before I click
on my "OK" button to close the window, no action is sent. Then, the next
time I open the window, the action is immediately sent (and the text
field reflects the updated value).


Number 1 doesn't affect my program negatively -- it just forces my prefs
controller object to do some un-needed processing. However, is there a
way to prevent this, or should I just not worry about it?

Number 2 is more troublesome, because you should be able to edit a text
field in a prefs window and then immediately click on "OK" to close the
window and have the new prefs stick. Just wondering if there is a
commonly preferred way to handle this. I could add code to the method
that closes the window which polls all text fields for their value
before closing, but that hardly seems like a clean solution.

Thanks in advance for any help.

[matt neuburg]

In <1060811321.698956@sj-nntpcache-5> Jamal Bernhard wrote:

> 2. If I edit data in one of the text fields but don't deselect the
> text field (via tab, return, clicking on another control, etc) before
> I click on my "OK" button to close the window, no action is sent.

Don't *fight* the AppKit - *use* it. You don't get an action message
from a textfield under those circumstances, so don't set things up in
such a way that you rely on this. That is not what an action message in
a textfield is for.

What you want to do (keep track of the values of the textfields without
polling them all as the window closes) is perfectly reasonable. But you
need to drop back ten yards and punt. There are many, many perfectly
good ways to do this - implement windowDidUpdate:, implement
controlTextDidChange, use an NSFormatter, etc., etc. - but you aren't
going to think of *any* of them if you keep trying to use the AppKit in
a way that's not intended.

m.

--
matt neuburg, phd = [email]matt@tidbits.com[/email], [url]http://www.tidbits.com/matt[/url]
REALbasic: The Definitive Guide! 2nd edition!
[url]http://www.amazon.com/exec/obidos/ASIN/0596001770/somethingsbymatt[/url]
Subscribe to TidBITS. It's free and smart.

[Jamal Bernhard]

matt neuburg wrote:

> What you want to do (keep track of the values of the textfields without
> polling them all as the window closes) is perfectly reasonable. But you
> need to drop back ten yards and punt. There are many, many perfectly
> good ways to do this - implement windowDidUpdate:, implement
> controlTextDidChange, use an NSFormatter, etc., etc. - but you aren't
> going to think of *any* of them if you keep trying to use the AppKit in
> a way that's not intended.

Thanks for the pointers to areas I can check out. I'm a newbie to OOP
and Cocoa (about 25 hours put in thus far), so I haven't gotten to
-windowDidUpdate or -controlTextDidChange yet. But, I knew that either
(a) I was missing something obvious about NSTextField actions (in which
case someone here could straighten me out), or (b) I needed to learn
more (in which case someone here could point me in the right direction).
You have confirmed that it is (b). :-)

And, for the record, I *am* a good programmer and don't want to use the
AppKit in unintended ways. (Otherwise, I would have just said screw it
and plowed ahead trying to poll the values when the window closed
instead of posting my question!) In fact, some co-workers might say I'm
a little too anal about good programming, as more than once I've
rewritten perfectly good code just because I found a new design slightly
more appealing. (Shhh, don't tell my manager.) And, of course, many of
the people that see me as anal I consider to be bad programmers.

Anyway, when first starting out with a complex tool, one understands
such a small percentage of what's out there that trying to find a good
way to accomplish even something simple (like keeping track of text
field values in a clean way) can be like looking for a needle in a
haystack. Thanks again for showing me where to look.

[Eric Pepke]

Jamal Bernhard <jamalb.spambegone@pacbell.goodbyespam.net> wrote in message news:<1060832382.254766@sj-nntpcache-3>...

> And, for the record, I *am* a good programmer and don't want to use the
> AppKit in unintended ways. (Otherwise, I would have just said screw it
> and plowed ahead trying to poll the values when the window closed
> instead of posting my question!)

It isn't a question of your skills as a programmer. It's something that's
unusual about Cocoa, which sets it apart from Carbon, Classic, WIN32,
Java AWT, Java Swing, Palm OS, and every other API I've ever worked on.
It's something that's hard to describe, but it's a bit like petting a cat--
you have to pet in the correct direction. Doing things the wrong way
in Cocoa is usually much, much harder than to things the right way,
to the point that the difficulty of doing something is a good indicator
of whether it's the right thing to do. The difference is much more dramatic
than in any other API I've ever used.

[matt neuburg]

In <1060832382.254766@sj-nntpcache-3> Jamal Bernhard wrote:

> matt neuburg wrote:
>

>> What you want to do (keep track of the values of the textfields
>> without polling them all as the window closes) is perfectly
>> reasonable. But you need to drop back ten yards and punt. There are
>> many, many perfectly good ways to do this - implement
>> windowDidUpdate:, implement controlTextDidChange, use an NSFormatter,
>> etc., etc. - but you aren't going to think of *any* of them if you
>> keep trying to use the AppKit in a way that's not intended.

>
> And, for the record, I *am* a good programmer and don't want to use
> the AppKit in unintended ways

I didn't say anything about your programming abilities. I am giving you
a very valuable piece of insight ("*use* the AppKit, don't *fight* it",
is what I said). I am a teacher, and I'm telling you that if you can
wrap your head around this little philosophical nugget (or koan) you
will find Cocoa much easier (and better) than you ever dreamed. Instead,
now you choose to fight not just Cocoa, but me. Ah, well. You can lead a
horticulture but you can't make her think. m.

--
matt neuburg, phd = [email]matt@tidbits.com[/email], [url]http://www.tidbits.com/matt[/url]
REALbasic: The Definitive Guide! 2nd edition!
[url]http://www.amazon.com/exec/obidos/ASIN/0596001770/somethingsbymatt[/url]
Subscribe to TidBITS. It's free and smart.

[Tom Harrington]

In article <20030814064402584-0700@news.la.sbcglobal.net>,
matt neuburg <matt@tidbits.com> wrote:

> I didn't say anything about your programming abilities. I am giving you
> a very valuable piece of insight ("*use* the AppKit, don't *fight* it",
> is what I said). I am a teacher, and I'm telling you that if you can
> wrap your head around this little philosophical nugget (or koan) you
> will find Cocoa much easier (and better) than you ever dreamed.

It's sometimes easier said than done, for people new to Cocoa. Sure,
it's better to work with it than against it, but until you grok how it
likes to work, it's not always apparent how to do that.

--
Tom "Tom" Harrington
Macaroni, Automated System Maintenance for Mac OS X.
Version 1.4: Best cleanup yet, gets files other tools miss.
See [url]http://www.atomicbird.com/[/url]

[Paul Mitchum]

Jamal Bernhard <jamalb.spambegone@pacbell.goodbyespam.net> wrote:

> matt neuburg wrote:
>

> > What you want to do (keep track of the values of the textfields without
> > polling them all as the window closes) is perfectly reasonable. But you
> > need to drop back ten yards and punt. There are many, many perfectly
> > good ways to do this - implement windowDidUpdate:, implement
> > controlTextDidChange, use an NSFormatter, etc., etc. - but you aren't
> > going to think of *any* of them if you keep trying to use the AppKit in
> > a way that's not intended.

>
> Thanks for the pointers to areas I can check out. I'm a newbie to OOP
> and Cocoa (about 25 hours put in thus far), so I haven't gotten to
> -windowDidUpdate or -controlTextDidChange yet. But, I knew that either
> (a) I was missing something obvious about NSTextField actions (in which
> case someone here could straighten me out), or (b) I needed to learn
> more (in which case someone here could point me in the right direction).
> You have confirmed that it is (b). :-)

There's a great little freeware application out there called Cocoa
Browser. It turns the built-in Cocoa documentation into an
easily-browseable heirarchical window (as many windows as you want,
actually; I usually have one for appkit and one for foundation). Get it
here: <http://makeashorterlink.com/?C2D052895>

If you get it, you can run it, click on AppKit/Classes, and click on
NSTextField. You'll see it doesn't have any delegate methods, and is a
subclass of NSControl. So click on NSControl, and there's a list of all
the delegate methods NSTextField inherits from NSControl, including
-controlTextDidChange. Click on the methods for a description.

I've learned more quickly about Cocoa by virtue of using Cocoa Browser
than I would have with just the HTML documentation. Get it. :-)

[Jamal Bernhard]

Paul Mitchum wrote:

> There's a great little freeware application out there called Cocoa
> Browser. It turns the built-in Cocoa documentation into an
> easily-browseable heirarchical window (as many windows as you want,
> actually; I usually have one for appkit and one for foundation). Get it
> here: <http://makeashorterlink.com/?C2D052895>

awesome -- thanks!