MultiInputDialog does a close -> show in the same callback,
so if we don't actually keep it in sync with the actual state, we lose
the keyboard and essentially softlock the UI, which is Very Bad(TM).
NOTE: InputDialog has its own keyboard_hidden flag, and it looks...
fairly nightmarish.
@ -64,7 +64,7 @@ local InputText = InputContainer:extend{
for_measurement_only=nil,-- When the widget is a one-off used to compute text height
for_measurement_only=nil,-- When the widget is a one-off used to compute text height
do_select=false,-- to start text selection
do_select=false,-- to start text selection
selection_start_pos=nil,-- selection start position
selection_start_pos=nil,-- selection start position
is_keyboard_hidden=false,-- to be able to show the keyboard again when it was hidden
is_keyboard_hidden=true,-- to be able to show the keyboard again when it was hidden. (On init, it's the caller's responsibility to call onShowKeyboard, as far as we're concerned, it's hidden)
}
}
-- These may be (internally) overloaded as needed, depending on Device capabilities.
-- These may be (internally) overloaded as needed, depending on Device capabilities.
@ -132,9 +132,8 @@ local function initTouchEvents()
ifself.parent.onSwitchFocusthen
ifself.parent.onSwitchFocusthen
self.parent:onSwitchFocus(self)
self.parent:onSwitchFocus(self)
else
else
ifself.is_keyboard_hidden==truethen
ifself.is_keyboard_hiddenthen
self:onShowKeyboard()
self:onShowKeyboard()
self.is_keyboard_hidden=false
end
end
end
end
-- zh keyboard with candidates shown here has _frame_textwidget.dimen = nil.
-- zh keyboard with candidates shown here has _frame_textwidget.dimen = nil.