[sldev] LLUICtrl::onFocusLost() callback

[Richard Nelson]

Hi Alissa,

I'm one of the UI guys at Linden Lab.  I hope I can help you with your problem.

I assume you are calling handleUnicodeCharHere directly from the commit callback.  If you are relying on LLWindowCallback, it won't be called until the beginning of the next frame (using whatever is in the OS input queue), at which point keyboard focus has moved on, regardless of the timing of the call to onFocusLost().

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.  For example:

BOOL LLLineEditor::handleUnicodeCharHere(llwchar uni_char, BOOL called_from_parent)
{
	// ...hidden code...

	if ( (gFocusMgr.getKeyboardFocus() == this) && getVisible() && !mReadOnly)
	{
		handled = TRUE;

should become

BOOL LLLineEditor::handleUnicodeCharHere(llwchar uni_char, BOOL called_from_parent)
{
	// ...hidden code...

	if ( getVisible() && !mReadOnly)
	{
		handled = TRUE;

Same with LLTextEditor.  This check for having keyboard focus is redundant in the typical case, as keystrokes are initially dispatched based on keyboard focus, and it embeds a high level constraint (where keystrokes go) deep into a particular widget handler, where it doesn't belong.  I'm not particularly happy with the getVisible() there either, but we'll leave that fix for another time.

Let me know if this doesn't work or you have any questions.

Richard

On Thu, 23 Aug 2007 07:02:18 -0700, Alissa Sabre <alissa_sabre at yahoo.co.jp> wrote:

> Linden/SLDev developers,
>
> I've been working on improving Chinese/Japanese/Korean text input on
> the viewer (See, e.g., VWR-250).  I'm facing a blocker now.  I want to
> hear your opinions.
>
> In my latest patch, preedit (aka composition or unconfirmed) string is
> shown on the LLTextEditor and LLLineEditor components as the user type
> and then sent to the components buffer (through handleUnicodeCharHere)
> when the user perform a commit (aka comple or confirm) operation.  This
> is fine.
>
> The problem is the case that the user changed the keyboard focus to
> another UI control befor comitting the preedit string.  We need to
> automatically commit the contents of the preedit before actually
> switch the focus, because that's what the user expects.
> Unfortunately, it doesn't work well now.
>
> Exising LLUICtrl provides a callback onFocusLost().  I first thought
> that issueing a commit operation from LLTextEditor::onFocusLost() and
> LLLineEditor::onFocusLost() solves the problem, but it didn't work.
> onFocusLost() is invoked *after* the focus has been lost, but I need a
> callback invoked just *before* the focus is lost.  More precisely
> speaking, in the existing code, when the onFocusLost() callback is
> invoked, gFocusMgr.childHasKeyboardFocus(this) returns false, because
> the focus is set to the new component that receives the focus.  I need
> a callback that is invoked during
> gFocusMgr.childHasKeyboardFocus(this) returns true, so that the
> LLWindowCallback::handleCharHere() to be invoked during the automatic
> commit operation is delivered to this.
>
> I have two alternatives here.  I want to hear from you which you think
> is better.  (Or another alternative if you have one.)
>
> (a) Change the timing that the existing onFocusLost() is invoked to
>     facilitate my requirement.
>
> (b) Add a new callback, say onFocusBeingLost(), that is invoked
>     immediately before the keyboard focus is lost, so that I can use
>     it.
>
> The alternative (b) is safer than (a) in that it makes less impact on
> the existing code.  However, such ad hoc additions of methods to
> handle special cases will make the SL viewer code something like
> Windows API, and I don't want to do so unless absolutely needed.
>
> I believe there is no existing code that depends on the timing whether
> onFocusLost() is invoked before or after the actual focus-loosing.  I
> examined all uses of onFocusLost() callback in viewer source set.
> Hence, changing the timing should cause no problem.  Of course, I
> can't see server-side programs, and I have no idea the same thing is
> true for LL's so-called "server-side development tools that share UI
> components with viewer."
>
> Comments?
>
>     Alissa Sabre
> --------------------------------------
> Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
> http://pr.mail.yahoo.co.jp/toolbar/
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>