[Top][All Lists]

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

Re: NSTextField questions

From: David Ayers
Subject: Re: NSTextField questions
Date: Tue, 24 Sep 2002 23:57:25 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826

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:
might help. (But be careful, it might be to much detail.)

And I'll look into the notification bug.


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:
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:
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.


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.
+ */
+  // 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))

reply via email to

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