|
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.
Cheers, Dave
[Prev in Thread] | Current Thread | [Next in Thread] |