[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

first responder and text field again

From: Dirk Lattermann
Subject: first responder and text field again
Date: Wed, 13 Nov 2002 20:59:49 +0100
User-agent: Mutt/1.4i


Since David's answer (and patch) to my last posting about this,
the first responder logic of NSTextField seemed to behave
reasonably, thanks!

But now, I am experiencing something strange again:

I have subclassed NSTextField, overriding the becomeFirstResponder.
This method does much of checking and internal bookkeeping, at one
point setting the stringValue of some NSTextFields.

I.e., when the user clicks on field A, the values of fields A and B are
set via setStringValue before becomeFirstResponder (of A) returns.
When A's value is changed, its delegate (which in my case is field A)
is sent the controlTextDidBeginEditing: and
controlTextDidChange: messages.
When B's value is changed, no delegate messages are sent (to B, the
delegate of B).

I think this is not correct, but maybe it is and someone of you can
explain to me, why?

I have reproduced the situation with a minimal set of files/
classes.  These six files are attached in a tarball, if this
interests you, but perhaps the state of the text/first responder
mechanism is much in flux at the moment and this is not a good moment
to look into it?

Also, I spotted that NSTextField's becomeFirstResponder seems to call
[self acceptsFirstResponder], so that there's always a sequence of
acceptFR-becomeFR-acceptFR in the output of my little app.
I'm not sure whether this is wrong or right, either, but I stumbled
over it.

Dirk Lattermann

Attachment: test.tar.gz
Description: application/tar-gz

reply via email to

[Prev in Thread] Current Thread [Next in Thread]