[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:
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))
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: NSTextField questions,
David Ayers <=