[sldev] LLUICtrl::onFocusLost() callback

[Alissa Sabre]

Thank you folks for quick responses!

I love to hear from you more on this issue before decision, but I'm
giving some details to answer to Richard's comment.

Richard:
> I assume you are calling handleUnicodeCharHere directly from the commit callback.

Well, sorry for the confusion on the wording.  All the word "commit"
in my previous message refers to an operation that is specific to
input methods.  I never refereed to the _commit_ operations (as
LLUICtrl::onCommit()) provided in the LLUI controls.

In my scenario, the onFocusLost() callback doesn't call
handleUnicodeCharHere() directly.  Instead, the onFocusLost() will
issue an operating system specific API (through platform dependent
implementation of LLWindow class).  It is ImmNotifyIme() with dwAction
set to NI_COMPOSITIONSTR and dwInde set to CPS_COMPLETE if you are on
Windows, and FixTSMDocument() if you are on MacOS.  I meant these
calls "commit operation."

On either OS, these calls send one or more messages (events) to the
calling applicatin before return, through the standard window
procedure or event handler.  On Windows, it includes
WM_IME_COMPOSITION.  This message will trigger several actions and
finally causes a sequence of several WM_CHAR messages.  On MacOS, it
includes kEventTextInputUpdateActiveInputArea, and the event triggers
kEventTextInputUnicodeForKeyEvent.

These messages are handled by existing codes in LLWindowWin32 or
LLWindowMacOSX, causing several invokations to
LLWindowCallback::handleUnicodeChar.  This call to handleUnicodeChar
is processed normally.

So the point is, when onFocusLost() is invoked against a control X,
handleUnicodeChar is issued through the usual event handling
mechanisms, and I want the handleUnicodeChar is consumed by the
control X, not by the control that will be receiving the next keyboard
focus.

> Instead of changing the timing of the focus lost callback (which, as
> you suggested, can be a touchy proposition), let me suggest a simple
> modification to character handling for text and line editors: simply
> remove the check for having keyboard focus.

Simply removing the focus test doesn't work in my case, since the
handleUnicodeChar will be dispatched to another control.

Well, however, I got another idea hearing this.  My code hooks
WM_IME_COMPOSITION and kEventTextInputUpdateActiveInputArea already,
and I could create a _short_cut_ to the control's
handleUnicodeCharHere bypassing both OS's event handler and LLUI event
dispatching code.

Let me think about it.

Thank you for the interesting insight and suggestion.

    Alissa Sabre
--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/