Re: first responder and text field again

[David Ayers]

Dirk Lattermann wrote:

> 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?
>
>  
Hi Dirk,

Well to explain what's happening... during the call [super 
becomeFirstResponder] the field edititor is setup for the NSTextField. 
Then setStringValue: sends an abortEditing which clears the field 
editor for the text field again, and sets the value to be displayed. 
Now you have an NSTextField that's firstResponder (well actually the 
fieldEditor is) with the new value but it loses it's reference to it's 
field editor :-( ! Yet the fieldEditor's delegate is still the 
NSTextField :( !! But for reasons I haven't tracked down yet, the window 
get a couple more makeFirstResponders: with that NSTextField upon 
mouseDown: (sorry little time right now to track it down, may be next week.)

But the point is...

The way test system mechanics work, it's not really meant for an 
NSTextField to be it's own delegate.  The Model-View-Controller paradigm 
(MVC) seperates the "View" (NSTextView) classes from the "Controller" 
classes.  The point is that the "Controller"

(either one general controller for all UI elements of a small app
or of a Window (see NSWindowController)
or even an instance of a specialised "controller" class like 
EOAssociation that's responsible for a single NSTextField)

coordinates the NSTextField(s), while the NSTextField is only 
responsible for itself, notifing it's delegate, handling its cell, 
setting up it's field editor and so on.

The relationship of a NSTextField to the app and/or other NSTextFiels 
should be coordinated by an overlaying "Controller" (which may make its 
decisionions based on the state of a "Model")

(When I find some time, I'll try to put an short introduction to MVC on 
wiki.gnustep.com, or does someone else already have someting they could 
just copy&paste there?)

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. (ie why do you want NSTextField A to change 
its conents when NSTextField B becomes first responder? Is NSTextField A 
some type of "inspector" of the current First Responder?)  I can't tell 
you off the top of my head how to do it, but I'm sure GORM implements 
something like this.  I'll look into it when I find some time.

Cheers,
Dave