Re: NSTextField questions

[David Ayers]

Dirk Lattermann wrote:

> Wow. It's a bit clearer now. I was wondering why a text field gains
> firstResponder status and loses it immediately again. I suspected
> the field editor, but the semantics of this is rather difficult
> to find out from the API specification.
I know :( but hey, maybe we can work to get our own documentation soon.

> I'm currently hacking together an naive database GUI that is a little
> bit like a very lightweight version of oracle's forms runtime.
> Right now, it supports only text fields for items (I'm not quiet sure
> how to extend this to other NSControls, because I don't see how to
> "add member variables to NSControl and use functionalities of its
> subclasses", but that's another issue...).
> For several things, e.g. to move from one record in a block to another
> by pressing a "next record" button, I need to know the active block
> which is the block to which the active item (text field) belongs.
> The active item is the one which has the input focus, so I'm trying
> to be notified when the text field gets the input focus.
>
> I don't know how to get this info from the window later when I need it,
> for example when a click on "next record" has occured, because then,
> the firstResponder has changed again.
Well I think what you are looking for is the mechanics that 
EODisplayGroup and EOAssociations are supposed to handle. The 
EODisplayGroup handles the EOEntity's (in the simplest case a DB-Table) 
current selection and the EOAssociations as delegates of the NSTextField 
which are also bound to the EODisplayGroup coordinate the display. So 
you might wish to wait for gdl2 to come out, but I can't tell you how 
much of this will actually work once it comes out. Therefor you might 
still be better off implementing it yourself. But maybe browsing through:
http://developer.apple.com/techpubs/webobjects/WebObjects_4.5/System/Library/Frameworks/EOInterface.framework/ObjC_classic/EOInterfaceTOC.html
might help. (But be careful, it might be to much detail.)

> > And I'll look into the notification bug.
> >    
>
> Great!
The first responder mechanics of NSTextField have been fixed! And here 
is patch that fixes your problem. As I had assumed, the 
NSTextDidBeginEditingNotification was triggerd prematurely. I found docs:
http://developer.apple.com/techpubs/macosx/Cocoa/TasksAndConcepts/ProgrammingTopics/TextStorageLayer/index.html
stating that "The *textShouldBeginEditing:* and *textDidBeginEditing:* 
messages are sent only once during an editing session. More precisely, 
they're sent upon the first user input since the NSTextView became the 
first responder."

So I've included a patch that checks the first responder status, since 
the field editor is not FR while it is being setup. My patch also 
includes the provision stated in:
http://developer.apple.com/techpubs/macosx/Cocoa/Reference/ApplicationKit/ObjC_classic/Classes/NSTextView.html
that the method should return NO immediatly, if the text field is not 
editable.

Please update from cvs before applying the patch!

Looking into this, I'm not sure whether it is at all correct that 
shouldChangeTextInRange:replacementString: should be called in 
setTextColor:range: at all, or in some of the other methods it is 
currently called in. I'm running a couple of tests on OPENSTEP 
Enterprise 4.2 to see where and when they are called there. If some one 
with enough insight in to the mechanics can verify that these calls are 
correct, then I would appreciate a pointer.

Cheers,
Dave

Index: Source/NSTextView.m
===================================================================
RCS file: /cvsroot/gnustep/gnustep/core/gui/Source/NSTextView.m,v
retrieving revision 1.105
diff -u -r1.105 NSTextView.m
--- Source/NSTextView.m 24 Sep 2002 01:29:14 -0000      1.105
+++ Source/NSTextView.m 24 Sep 2002 20:22:34 -0000
@@ -2244,8 +2244,20 @@
 
 - (BOOL) shouldChangeTextInRange: (NSRange)affectedCharRange
               replacementString: (NSString*)replacementString
+/*
+ * If the receiver is first responder, this method is responsible for 
+ * checking with the delegate, whether textShouldBeginEditing: and to 
+ * post the NSTextDidBeginEditingNotification, if it should.
+ * This method returns NO immediatly, if the corresponding text field
+ * is not editable. This insures that no user action can accidentally
+ * edit the contents.
+ */
 {
-  if (BEGAN_EDITING == NO)
+  // Insure that no user action can edit the text field indirectly 
+  if (_tf.is_editable == NO)
+      return NO;
+
+  if (BEGAN_EDITING == NO && [_window firstResponder] == self)
     {
       if (([_delegate respondsToSelector: @selector(textShouldBeginEditing:)])
          && ([_delegate textShouldBeginEditing: _notifObject] == NO))