Re: Bug in NSAttributedString (?)

[Pierre-Yves Rivaille]

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?