gui-cs
Application.Driver.SendKeys should be retired
Is your feature request related to a problem? Please describe.
This method is problematic for 2 reasons:
- It assumes that all drivers operate on
charand/orConsoleKey - It requires/assumes that the user knows what combination of
keyCharandConsoleKeydescribe a given key press
The actual raw inputs are:
| Driver | Class |
|---|---|
| Win | InputRecord (and KeyEventRecord) |
| Net | ConsoleKeyInfo |
Furthermore this method is not implemented in v2 drivers. See ConsoleDriverFacade:
public void SendKeys (char keyChar, ConsoleKey key, bool shift, bool alt, bool ctrl)
{
// TODO: implement
}
Finally if we were to have a shared implementation of spawning keystrokes - then it should be the class that is used within Terminal.Gui itself to represent key presses in driver agnostic way, specifically:
class Key : EventArgs, IEquatable<Key>
Describe the solution you'd like Mark obsolete or internal or remove
Describe alternatives you've considered or internal or remove
Additional context Add any other context or screenshots about the feature request here.
SendKeys is used in two Scenarios:
SendKeysVkPacketSimulator
Neither of these Scenarios are valid in a world where only the v2 driver architecture exists. They can safely be deleted.
It is used in these unit tests:
FileDialogTestsAppendAutocompleteTestsTextFieldTests
The proper way for these tests to inject key input is to use Application.RaiseKeyDownEvent and porting them should not be hard.
The proper way for these tests to inject key input is to use
Application.RaiseKeyDownEventand porting them should not be hard.
Use Application.RaiseKeyDownEvent isn't really the best solution to handle with surrogate pairs because this method is only invoked when a valid key should be handled. So, the high and low surrogates should never be sent to the Application.RaiseKeyDownEvent method alone because will throw the exception System.ArgumentOutOfRangeException: 'Specified argument was out of the range of valid values. (Parameter 'value')' in the Key.GetKeyString method. That was handled in the SendKeys method, avoiding send the high surrogate alone to the Key class and only send the surrogate pair. Are you really sure you want to remove the SendKeys method which will complicating dealing with high and low surrogates in the Key class? If affirmative what alternative code we need to create to avoid call Application.RaiseKeyDownEvent if it's a high or low surrogates throwing an exception in the Key class? Any suggestion is appreciated, thanks.
I'll note again: SendKeys is NEVER called from anywhere but two Scenarios (and some unit tests). One, a VK key simulator that has no real use, and one a Scenario designed to just test the SendKeys API.
What is the real END USER use-case you are worried about?
If a surrogate pair can't be typed and thus passed to Application.RaiseKeyDownEvent then what is the point?
If a surrogate pair can't be typed and thus passed to
Application.RaiseKeyDownEventthen what is the point?
But can be copied and pasted.
If a surrogate pair can't be typed and thus passed to
Application.RaiseKeyDownEventthen what is the point?But can be copied and pasted.
Pasting strings with surrogate pairs works great with the v2 drivers and does not invoke the SendKeys api.
It's broken on WindowsDriver, but even there it has nothing to do with SendKeys.
What do you mean?
Pasting strings with surrogate pairs works great with the v2 drivers and does not invoke the
SendKeysapi.
Worked first in the v1 drivers and then in the v2 drivers after I fixed them.
It's broken on WindowsDriver, but even there it has nothing to do with
SendKeys.
Pasting isn't broken in the WindowsDriver now. Try paste in surrogate pair in the TextField and TextView and you'll it's working.
What do you mean?
Only in the SendKeys scenario was throwing before my fix but I'll remove all the scenarios and unit tests that are using the SendKeys method and thus terminating this discussing.