Re: Advice on restricting/monitoring character input in NSTextView
Re: Advice on restricting/monitoring character input in NSTextView
- Subject: Re: Advice on restricting/monitoring character input in NSTextView
- From: Scott Lehman <email@hidden>
- Date: Tue, 7 Feb 2006 12:09:51 -0800 (PST)
It was the need to process strings longer than one
character from the pasteboard that led me to look
beyond the delegate methods - I want to modify rather
than disallow input. I've been trying what you
outlined below (I am doing rich text), but am failing
to get it to play nicely with undo. I can get the
appearance of proper functionality by querying the
state of the undo manager, but still raise out of
bounds exceptions.
It looks like modifying the string that late in the
game poses issues when dealing with undo since the
original string is already registered. I bet it's
still possible, but at this point, I'm thinking there
has to be a better solution.
I want undo, so is there an easy way to modify text
input before the actions that are registered with the
undo manager?
That makes me think an NSTextView subclass might be
best, but I haven't pieced together precisely how the
input flows thru it yet, or if there are new issues
when subclassing it.
Thanks,
Scott
PS - Thanks for the tip on the Smart Quotes article.
That is something I will deal with, and indidentally,
his method for inserting processed strings goes direct
to the text storage, bypassing undo .
--- Keith Blount <email@hidden> wrote:
> You shouldn't need to subclass for this - you were
> on
> the right track in the first place.
>
> The delegate method
>
-textView:shouldChangeTextInRanges:replacementStrings:
> (or you can use the singular version for pre-Tiger
> or
> text views that don't allow multiple selection) will
> get called before undo gets set up. So if you
> restrict
> input there, all that will happen is that whenever
> the
> user tries to type something restricted, you have
> this
> method return NO and nothing will happen when the
> user
> types (or you can provide an NSBeep() or a message
> or
> whatever you want within that method.
>
> This method will also get called whenever you try to
> paste anything into your text view. This is probably
> the sort of thing you want (note that I haven't
> tested
> this code so there may be errors in it - it was just
> a
> quick effort and can definitely be improved):
>
> -- code snipped for message size --
>
> That should deal with preventing the user from
> typing
> consecutive spaces or tabs. Dealing with a paste of
> multiple characters is more difficult. In that case,
> you will need to parse through the string being
> pasted, looking for restricted characters.
> NSString's
> -rangeOfString:options:range: would probably be best
> for this, although you could also look at NSScanner.
> The trouble is, what to do if there is a restricted
> character? You could return NO and disallow the
> paste
> entirely, which would be by far the simplest
> solution.
> Otherwise, things get tricky. If your text view is
> plain text only, it's not too difficult. You would
> just modify the new string and place it in the text
> view yourself, still returning NO to the method.
> (This
> is because, unfortunately, the above method allows
> you
> to stop the new string getting entered, but it
> doesn't
> allow you to modify the actual string unless you
> insert it yourself.) Google for Andrew Stone's
> tutorial on smart quotes for handling this manually.
> If you have a rich text view, it's more tricky. In
> that case, you would probably want to save the range
> of text that has been changed in the above method
> (NSMakeRange(affectedRange.location, [newString
> length]) ), and then examine and change that range
> in
> -textDidChange:, once the text has been inserted
> into
> the text view. The user might be able to undo back
> to
> a state you don't want in that case, though.
>
> Hope that helps,
> Keith
>
> --- ORIGINAL MESSAGE ---
>
> From: Scott Lehman
> Subject: Re: Advice on restricting/monitoring
> character input in
> NSTextView
> To: Keith Wilson
> Cc: email@hidden
> Message-ID:
>
<email@hidden>
> Content-Type: text/plain; charset=iso-8859-1
>
> Well I have to confess that I'm not sure what to do
> with that. I thought the docs state that the field
> editor is for controls, which made sense to me -
> having an NSTextView instance as a field editor for
> an
> NSTextView seems redundant and unecessary. Or is
> it?
>
> I realize now that while the NSTextStorage delegate
> may provide a nice hook, it poses problems for undo.
>
> If I filter out a key stroke, it should be before
> the
> action is registered for undo.
>
> So now I'm thinking subclassing NSTextView might be
> the way to go. Is it as simple as:
>
> -Override insertText: to include
> filtering/processing
> (this covers both key press and pastes, correct?)
> -Either call [super insertText:aString] with any
> input
> I want, or return immediately if I want to ignore it
>
> ?
>
> Thanks,
>
> Scott
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden