Conversation
Contributor
|
Seems to have resolved the issue. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Before 3eb9cb9 the state of mouse buttons was not checked by
Inputwhen the active form did not "want mouse" (meaning, clicking on that form should not result in controller inputs being pressed or hotkeys being triggered). After, they are checked and so no non-"ignored" mouse input event would be generated if you click on the main form when TAStudio was active.This PR fixes that by having
Inputdetect when the active form changes, and then clears its mouse state and generates new mouse events. This only happens when moving from a non-mouse-wanting form to a mouse-wanting form, which seems consistent with the behavior of 2.11 but might not be ideal. This is because clicking on TAStudio while the main form is active will result in a mouse input most of the time;Inputsees the mouse button being pressed beforeForm.ActiveFormchanges. If we clear mouse state and generate new events going the other way too then any controller inputs bound to the mouse button will be quickly released afterActiveFormchanges, but the inputs will still happen. But even with this issue, this is an improvement over 2.11. In 2.11 if you click on TAStudio while the main form is active, any controller input bound to the mouse button will be pressed and will not be released when the mouse button is released. Now, it will be released when the mouse button is released.I also had to change call sites of
Input.ControlInputFocus, which previously was being called in forms'OnActivatedandOnDeactivatemethods. This doesn't make any sense to me, since the call toInput.ControlInputFocusinOnDeactivateis not required; mouse inputs won't happen when the form is active becauseInputchecks which form is active. EDIT: It had to be changed because if the form does not remain in the wanting-mouse state,Inputmay see it does not want mouse (becauseControlInputFocushad not yet been called inOnActivated) and thus not produce new mouse events when the active form switches. It's a race condition.Please test, @RetroEdit.
Fixes #4717
Check if completed: