Preventing keystroke fallthrough on text field usage between different mods(InputLockManager)

[Diazo]

Alright, due to a conflict in how my mod (Action Groups Express) and another mod (Camera Focus Changer) handle the InputLockManager class, I've spent the evening digging into it and for discovered that for all our mods to play nicely together we as a community are going to need to come to a consensus about how we are going to handle the InputLockManager class.

Now, InputLockManager works on the ControlTypes enum which causes some wierdness as things don't quite behave as expected. A perfect example is the conflict between the two mods above that caused me to start looking into this.

First, Action Group Extended replaces the stock custom action groups so it applies a lock of ControlTypes.Custom_Actions to prevent KSP from activating those actions.

However, Camera Focus Changer was checking the InputLockManager.IsLocked(ControlTypes.All_Ship_Actions) to see if another mod had locked out commands due to a text entry field having focus.

This caused the conflict because ControlTypes.All_Ship_Actions is a complex enum with multiple values set to 1, one of which was ControlTypes.Custom_Actions as set by AGX. Therefore when Camera Focus Changer checked the InputLockManager class on the All_Ship_Actions control type, InputLockManager was telling it yes, All_Ship_Actions is indeed locked, even though Custom_Actions was the only control type actually locked. So Camera Focus Changer thought another mod had focus on a text box and ignored the keypress when it shouldn't have resulting in Camera_Focus_Changer appearing to be broken.

To keep this from happening again, we as a community need to do is decide which ControlType value we are going to use when we want to lock inputs due to a text entry field having focus so other mods know where to look when you set this control lock.

 

My suggestion after having done all this digging is the KeyboardInput control type.

If your mod has a text box, use the KeyboardInput controltype and execute "InputLockManager.SetControlLock(ControlTypes.KeyboardInput, "YourModName")" when the textbox gains focus, then remove the control lock with the .RemoveControlLock command when your text box loses focus.

If your mod accepts keystrokes for commands to control something, check to see if another mod has focus on a text box with the above lockout with "if(!InputLockManager.IsAllLocked(ControlTypes.KeyboardInput))". Note the !, you only want to execute if the check returns false. Also note that you are using the .IsAllLocked method, not the .IsLocked method.

My reasoning for this is that this is the ControlType Squad has given us to enable to ignore keyboard commands, that is exactly what we want other mods to do when our text box has focus for text entry. By locking this control type you only ignore keyboard commands, you don't lockout the onscreen buttons and commands that you can execute with the mouse.

However, this only works is everyone actually uses the InputLockManager class this way so everyone would have to buy in for this to be effective.

Thoughts? Any issues you see?

D.

Edited November 2, 2016 by Diazo

[zentarul]

I have to agree all the way. After checking the combinations of flag values for the ControlTypes, what makes the most sene is indeed to check that all parts of the control group you are insterested in are locked and that the only group which makes sense for generic text fields is ControlTypes.KeyboardInput.

[HebaruSan]

I have to say, if you were going to design an API that makes "let the user edit in this text box without messing up anything else" into a frustrating, intractable puzzle, you could hardly do a better job than how InputLockManager works.