[sldev] LLUICtrl::onFocusLost() callback

Richard Nelson richard at lindenlab.com
Fri Aug 24 14:54:39 PDT 2007


> 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.
>
Aaah, that clears things up a bit. :)

I was assuming you were calling handleUnicodeChar directly from LLLineEditor::onFocusLost().  Anything which routes back to the LLWindowCallbacks should only be processed on the next frame's call to LLWindow::gatherInput.

So yeah, sounds like your best bet is to cache the widget somewhere (I'd recommend using an LLViewHandle to do this, in case it was destroyed) or to do everything immediately from the onFocusLost() call.

R.


>
> 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/
>
>




More information about the SLDev mailing list