FROM : Aki Inoue
DATE : Wed Apr 13 07:27:12 2005
There is no way to determine if a single key down produces inline
holes. The context is totally private to input methods. In fact,
it's dangerous to assume only key events produce inline holes.
Certain input methods provide additional functionalities in the input
menu that could trigger generating inline holes without any user
event sent to the target app.
Once again 8-), what is your objective here ?
Aki
> Actually, now that I think a little harder, I would very much like
> to know before the textview has marked text in it.
>
> On my computer if I command-space it toggles between Japanese and
> US character modes (if that's that right description) If I am in
> US the text goes directly in, if I am in Japanese it goes into
> Marked text mode. What I need to do, is to determine when a keyDown
> event occurs (the first one for an entry is sufficient) if the
> character I am getting is a single byte character - and this
> directly entered - or a the first byte of multibyte character. In
> the case of multibyte entry - or markedText - I need to send the
> input somewhere else. This is a problem related to using Carbon /
> NSQuickDrawView inside Cocoa.
>
> The text system seems to know it is in marked text mode - since if
> I am in Japanese mode as soon as I enter a character the underlined
> text behavior starts.
>
> John Pattenden
>
>
>
>>
>> if ([myTextView hasMarkedText]) ...
>>
>> For more information, see my recent posts to this list on "how
>> input method editors work":
>>
>> "You should also be aware that in some cases the text view will
>> contain and display text that is only tentative, not yet confirmed
>> by the user. You can find out whether this is the case by calling
>> -hasMarkedText, and you can determine where it is using -
>> markedRange...."
>>
>> Douglas Davidson
>>
>>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (<email_removed>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>
> This email sent to <email_removed>
>
DATE : Wed Apr 13 07:27:12 2005
There is no way to determine if a single key down produces inline
holes. The context is totally private to input methods. In fact,
it's dangerous to assume only key events produce inline holes.
Certain input methods provide additional functionalities in the input
menu that could trigger generating inline holes without any user
event sent to the target app.
Once again 8-), what is your objective here ?
Aki
> Actually, now that I think a little harder, I would very much like
> to know before the textview has marked text in it.
>
> On my computer if I command-space it toggles between Japanese and
> US character modes (if that's that right description) If I am in
> US the text goes directly in, if I am in Japanese it goes into
> Marked text mode. What I need to do, is to determine when a keyDown
> event occurs (the first one for an entry is sufficient) if the
> character I am getting is a single byte character - and this
> directly entered - or a the first byte of multibyte character. In
> the case of multibyte entry - or markedText - I need to send the
> input somewhere else. This is a problem related to using Carbon /
> NSQuickDrawView inside Cocoa.
>
> The text system seems to know it is in marked text mode - since if
> I am in Japanese mode as soon as I enter a character the underlined
> text behavior starts.
>
> John Pattenden
>
>
>
>>
>> if ([myTextView hasMarkedText]) ...
>>
>> For more information, see my recent posts to this list on "how
>> input method editors work":
>>
>> "You should also be aware that in some cases the text view will
>> contain and display text that is only tentative, not yet confirmed
>> by the user. You can find out whether this is the case by calling
>> -hasMarkedText, and you can determine where it is using -
>> markedRange...."
>>
>> Douglas Davidson
>>
>>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (<email_removed>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>
> This email sent to <email_removed>
>
| Related mails | Author | Date |
|---|---|---|
| John Pattenden | Apr 12, 22:10 | |
| John Pattenden | Apr 13, 00:41 | |
| glenn andreas | Apr 13, 00:57 | |
| John Pattenden | Apr 13, 01:26 | |
| Douglas Davidson | Apr 13, 01:32 | |
| John Stiles | Apr 13, 01:36 | |
| John Pattenden | Apr 13, 02:00 | |
| John Pattenden | Apr 13, 02:38 | |
| Ben Kennedy | Apr 13, 02:42 | |
| John Stiles | Apr 13, 02:45 | |
| Aki Inoue | Apr 13, 07:23 | |
| Aki Inoue | Apr 13, 07:27 |






Cocoa mail archive

