Let us override functions of InputSystemUIInputModule

I know that we can write our own InputModule, but then assuming I'd want the most functionality of the current "standard" input module, but some functionality different, I won't dare copy paste all that code, and lose support of future updates.

My current need is to modify processing of mouse wheel scrolling that is sending IOnScroll only if the value is changed. Which makes total sense for the wheel, but then if I d want to emulate scrolling with a gamepad (LT-RT for example) the IOnScroll callback is going to be kicking in abruptly because of the check

Code (CSharp):

1. if (!Mathf.Approximately(scrollDelta.sqrMagnitude, 0.0f))

Now looking in the code I am seeing that all these processing functions are so nicely laid out, but we can't override these, even though I would find it beneficial

Code (CSharp):

1.            
2. // Left mouse button. Movement and scrolling is processed with event set left button.
3. eventData.button = PointerEventData.InputButton.Left;
4. state.leftButton.CopyPressStateTo(eventData);
5.  
6. ProcessPointerMovement(ref state, eventData);
7. ProcessPointerButton(ref state.leftButton, eventData);
8. ProcessPointerButtonDrag(ref state.leftButton, eventData);
9. ProcessPointerScroll(ref state, eventData);
10.  
11. // Right mouse button.
12. eventData.button = PointerEventData.InputButton.Right;
13. state.rightButton.CopyPressStateTo(eventData);
14.  
15. ProcessPointerButton(ref state.rightButton, eventData);
16. ProcessPointerButtonDrag(ref state.rightButton, eventData);
17.  
18. // Middle mouse button.
19. eventData.button = PointerEventData.InputButton.Middle;
20. state.middleButton.CopyPressStateTo(eventData);
21.  
22. ProcessPointerButton(ref state.middleButton, eventData);
23. ProcessPointerButtonDrag(ref state.middleButton, eventData);
24.  

 

Same goes for InputSystemUIInputModuleEditor, can't be inherited, when InputSystemUIInputModule itself can

 

I totally agree with this. For me it would be sufficient to override the `ExecuteEvents.Execute()` used in `InputSystemUIInputModule` to create event bubbling. I even started to copy the classes to redo it my own way, but the sheer number of internal classes that it depends on, makes it impossible to do, as some of them use static fields required to be set by input system internaly.

 

Making necromancy to up the idea.

It would also be so easy to add new kind of inputs (like supporting additional gamepad controls to manage custom UI navigation/interaction, or input control scheme changes).

 

I highly support this. In the project I am working on we were forced to expose the internal classes of the InputSystem using the assembly "internalsVisibleTo" property:

Code (CSharp):

1.  
2. /// Used to expose the internal function of the Unity.InputSystem to XXXX assembly
3. using System.Runtime.CompilerServices;
4. [assembly: InternalsVisibleTo("XXXXX")]
5.  

To allow us to overwrite what we needed (mainly we wanted to add custom bindings for UI navigation)