[Top][All Lists]

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

Re: first responder and text field again

From: David Ayers
Subject: Re: first responder and text field again
Date: Fri, 15 Nov 2002 00:25:37 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910

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.


reply via email to

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