Focus Issues

[CasualYT31]

Focus Issues

[texus]

Thanks again for the detailed information on what happens and figuring out where the issue lies.

After looking into this I believed that you fix was the best option (although I was going to apply the fix directly in Widget::setFocused as the other location where canGainFocus is called doesn't require the recursive check). However, I accidentally fixed it in a completely different way.

I changed the order of operations in all widgets that override the setFocused function. Instead of letting TextArea set its m_caretVisible to true and then changing the focused state with the Widget::setFocused call, I decided to first call Widget::setFocused and only set m_caretVisible to true if m_focused actually became true (which wouldn't be the case with your canGainFocus patch). Doing the same in the Container class has a very surprising side-effect: failing to focus the container would unfocus its child widgets.

So the following now happens:

• You call TextArea::setFocused
• The text area tells its parent that is has been focused
• The container tries to focus itself but fails because it is disabled
• The container notices that the text area is focused and tells it to unfocus (at the end of Container::setFocused)

This means that edit box ends up unfocused, without changing how canGainFocus works. Hopefully the change I just made doesn't break a bunch of other situations though.

the caret will not show (I assume this is because its immediate parent no longer has a focused widget?

This is because Widget::setFocused won't set m_focused to true if canGainFocus returns false. The caret is only shown when both m_caretVisible and m_focused are true. Technically m_caretVisible is never supposed to be true when m_focused is false, but the value of m_caretVisible is simply ignored if m_focused is false so it still worked correctly even though m_caretVisible was wrong.

Which I think makes the most sense, even if it might cause confusion if one attempts to invoke setFocused(true) on an indirectly disabled widget.

It agree that not allowing the focus is the best solution. It's easy to explain why focusing doesn't work in that case, and it can be easily implemented.

I feel like it would be nice to be able to apply set focus once the Group is re-enabled, though I imagine this will be more complicated

Yeah, that would probably be too complex to implement, and the focusing code is already quite complicated.