Re: first responder and text field again

[Dirk Lattermann]

Hi David!

On Fri, Nov 15, 2002 at 12:25:37AM +0100, David Ayers wrote:
> But the point is...
> 
> The way test system mechanics work, it's not really meant for an 
> NSTextField to be it's own delegate.

If I understand it right, this is from the "theoretical design",
"philosophical" point of view, but from a "pragmatic" view, it should
work nonetheless, right? (I don't understand the meaning of the
first part, "The way test system mechanics work")

> The Model-View-Controller paradigm 
> [explanation...]

It can see that separating these roles can help in designing clearer
architectures that are easier to understand and maintain. Didn't know
that there's a formulated "paradigm" that explains this.  Is this
written down somewhere in the Openstep spec or something else by Apple
or is it a (maybe even well-known) CS-"theory"?

> wiki.gnustep.com

Oh! I wasn't aware this existed! (But it's .org IIRC, checked
this morning)
> 

> Secondly it seems ... hmm unusual? to me, to change the contents of an 
> NSTextField while it is processing becomeFirstResponder.  But maybe you 
> have a good reason for it.  Maybe you can explain a bit more what "User 
> Effect" you are aiming at.

Well, as I already wrote, this is for a database GUI.
The text fields  part of "blocks", which represent a database table.
In a block, there may be several records representing table rows. The
text fields can show the column values in these records. When a block
doesn't contain a record and the user wants to create a record, he
clicks in a text field of the block to enter some value. At this
point, the record gets instantiated and filled with default values
(maybe a "create record" trigger is called that modifies the values).
Thus, if the user clicks into one text field, this field and others
must get their values modified.

The problem is that when the user edits text in an item (i.e., text
field), the record state is modified from "clean" to "changed"
so the system knows it must be written into the database later.
The fresh record (with its default values) is supposed to have
state "clean", however, and I was surprised why it hadn't.

I used a nasty, evil hack to solve the problem :-}
before changing the value via setStringValue, I moved the first
responder away to another, innocent text field via makeFirstResponder.
Really! That's true! Right in the middle of the text system's desperate
efforts to change the first responder! Cruel, but it works (I am aware
that this might not be by design). After
all event processing is done, the input focus is automatically in the
text field the user clicked.

> Is NSTextField A 
> some type of "inspector" of the current First Responder?)  I can't tell 

not in the above case, but I have two text fields showing the current
block and item (text field) name, too.

Thanks for having answered & explained!

Greetings,
Dirk Lattermann