[Top][All Lists]

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

Re: Bug in NSAttributedString (?)

From: Pierre-Yves Rivaille
Subject: Re: Bug in NSAttributedString (?)
Date: Sun, 03 Nov 2002 17:40:26 +0100

The implementation of the shouldChangeTextInRange:replacementString: method clearly follows the apple doc. I believe the problem is in the replaceCharactersInRange:withString: method. This method should not call shouldChangeTextInRange:replacementString:. The apple doc says "This method must be invoked at the start of any sequence of user-initiated editing changes" which *probably* means that it should *only* be called on user-initiated changes. The same problem occurs in GNUMail. When no message is selected, the textview is sent a setString: @"" message, and this message is ignored because shouldChangeTextInRange:replacementString: responds NO.

I believe the same problems happens with -setFont:ofRange:, -setColor:ofRange: -setAlignment:ofRange:.

I'll try to investigate further.

On 2002-11-02 20:50:45 +0100 Adam Fedor <fedor@doc.com> wrote:

This seems to occur in any NSTextField that is selectable but not editable, where the fieldEditor(NSTextView) refused to set it's string, dut to this:

diff -u -r1.114 NSTextView.m
--- NSTextView.m        29 Oct 2002 04:54:44 -0000      1.114
+++ NSTextView.m        2 Nov 2002 19:46:28 -0000
@@ -2255,8 +2255,8 @@
- (BOOL) shouldChangeTextInRange: (NSRange)affectedCharRange
                replacementString: (NSString*)replacementString
    if (_tf.is_editable == NO)
      return NO;

... but then later on tries to access the string. There's a big warning before this method that says it should always return NO when not editable to make sure the user can't change the string, but simply commenting out those two lines seems to work fine and there was no way that I could figure out that would change the string.

Does anyone who might no more about this have any comments?

reply via email to

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