Re: Subclassing NSTextView and characters with diacritical marks
Re: Subclassing NSTextView and characters with diacritical marks
- Subject: Re: Subclassing NSTextView and characters with diacritical marks
- From: Scott <email@hidden>
- Date: Thu, 14 Jun 2001 11:20:20 -0700
Jeff, check out the NSSecureTextField class. It's used in Mail.app for
their password field. I don't think it does random sequences of white
space(s) but it could be a place to look for ideas/hints on how to do it.
Aki, can you provide any additional hints?
Here's the class' description from the doc pages (note the last sentence):
NSSecureTextField is a subclass of NSTextField that hides its text from
display or other access via the user interface. It's suitable for use as a
password-entry object, or for any item in which a secure value must be kept.
An NSSecureTextField uses an NSSecureTextFieldCell, and adds behavior to the
text system to protect its text value. Your code can get the text field's
string value using the standard stringValue method, but users can't extract
it themselves. NSSecureTextField overrides many aspects of text editing to
prevent passing of the object's value out by mechanisms available to the
user (namely, through Cut, Copy, and Paste commands, and the Services
facility). This object also overrides the text system's drawing routine to
draw no text at all.
Enjoy!
Scott
------
"...there's no such thing as a plain name..."
http://www.domainjane.com
On 6/13/01 6:06 PM, "Jeff Cruikshank" <email@hidden> wrote:
>
Hi Aki,
>
>
My NSTextView subclass has two modes of display; hidden and visible.
>
When editing in hidden mode, each character entered is displayed as a
>
random sequence of white-space characters. Editing in visible mode is
>
the same as editing in a stock NSTextView. The idea is to prevent
>
someone from determining the length or content of the edited text, but
>
if the diacritical marks show up, that instantly gives an observer a
>
clue about the nature of the edited text.
>
>
Correct me if I'm wrong, but if I simply prevent keyDown from calling
>
interpretKeyEvents, won't that bypass the TSM? I realize this isn't very
>
friendly, but I know of no other solution.
>
>
Thanks!
>
Jeff
>
>
On Wednesday, June 13, 2001, at 10:42 AM, Aki Inoue wrote:
>
>
> Jeff,
>
>
>
> The marked deadkey display is tightly coupled with the processing in
>
> TSM.
>
> Currently there is no way to de-couple them easily.
>
>
>
> Besides, it is part of, not yet officially documented, Aqua guideline.
>
>
>
> Could you give me some more info why you need to disable it ?
>
>
>
> Thanks,
>
> Aki
>
>
>
> On 2001.06.11, at 18:56, Jeff Cruikshank wrote:
>
>
>
>> I'm having some problems with diacritical marks in my NSTextView
>
>> subclass. I would like to have full control over which characters are
>
>> displayed in my view, but despite my many attempts, I can't fully
>
>> control the display of these diacritical marks (they just keep
>
>> displaying regardless of how hard I try to prevent them from popping
>
>> up). In particular, when adding i (option-e + e) to my view, I would
>
>> like it to discard the initial keystroke and only display the
>
>> composite character (after the second 'e' is typed). I've looked at
>
>> the NSTextInput protocol, and setMarkedText:range: looks promising,
>
>> but simply overriding it and having it do nothing seems to cause
>
>> problems when the composite character is supposed to be added.
>
>>
>
>> Can someone shed some light on how I can prevent these marks from
>
>> drawing in my view?
>
>>
>
>> Thanks in advance,
>
>> Jeff