Skip to content

fix popups with inputboxes cancelling text input#4748

Draft
notimaginative wants to merge 1 commit into
scp-fs2open:masterfrom
notimaginative:text_input_fixes
Draft

fix popups with inputboxes cancelling text input#4748
notimaginative wants to merge 1 commit into
scp-fs2open:masterfrom
notimaginative:text_input_fixes

Conversation

@notimaginative

Copy link
Copy Markdown
Contributor

Text input is enabled when an inputbox is created and disabled when it's destroyed. If a screen has an inputbox and can trigger a popup that also has an inputbox, then text input is disabled when the popup is closed thereby preventing the original screen's inputbox from working.

Text input is enabled when an inputbox is created and disabled
when it's destroyed. If a screen has an inputbox and can trigger
a popup that also has an inputbox, then text input is disabled
when the popup is closed thereby preventing the original screen's
inputbox from working.
@notimaginative

Copy link
Copy Markdown
Contributor Author

Setting as draft since, although it addresses a particular problem found on the PXO screens, it doesn't really fix the underlying issue. So this PR may be scrapped in favor of a better solution.

Technically SDL_StartTextInput() should only be called when a user is required to enter text, as it can open an onscreen keyboard, so calling it when an input box is created is wrong. This PR toggles text input when an input box's focus is gained/lost. But it's unclear how well the existing retail ui code handles focus states so this may not be a complete solution.

A bigger issue is that SDL_StartTextInput()/SDL_StopTextInput() is called in individual situations rather than as a global setting. So text input can be stopped even when it's still needed and requires exiting and returning to a screen to re-enable input. Text input is started on creation of each input box ui element and stopped on deletion of each of those elements. It is also started/stopped when the debug console is used. And the newer rocket ui code will also toggle text input. These instances conflict with each other.

I think that, at a minimum, handling SDL_StartTextInput()/SDL_StopTextInput() in a global way is needed so that the number of starts must be matched by the number of stops. Going through to the retail ui code to confirm how well focus states are handled may also be a good idea.

Tagging @z64555 for his input on this.

@wookieejedi wookieejedi added fix A fix for bugs, not-a-bugs, and/or regressions. discussion This issue has (or wants) a discussion labels Oct 3, 2022
@z64555

z64555 commented Oct 4, 2022

Copy link
Copy Markdown
Member

The SDL wiki is a little thin on the usage of SDL_StartTextInput and SDL_StopTextInput, and judging by the behavior reported we'll need to make a mutex or counter to regulate when these two routines are actually called.

According to the SDL wiki, the two functions enable/disable certain events from generating, and again the reported behavior would suggest that they are managed in a simplistic way. We may be able to make a case with the SDL dev's or at least check their issue tracker to see if others have come into a similar issue.

@notimaginative notimaginative mentioned this pull request Oct 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

discussion This issue has (or wants) a discussion fix A fix for bugs, not-a-bugs, and/or regressions.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants