Changing Text Input Parameters Requires Enter

[scarmain]

Describe the bug
To change a text input value on NetworkTables, an Enter key is required to submit the value to NetworkTables. When this happens, it disables a active robot, because the driver station auto disables when the Enter key is pressed, even when Driver Station is out of focus. (and Space will E-Stop)

This makes calibrating/tuning robots harder, as you cannot live tune the robot functionally without having to disable every change. Teams that use the WpiLib Preferences API (or just standard NetworkTables) would be effected by this.

To Reproduce
Steps to reproduce the behavior:

1. Pull up a field using a text input value (aka any double value)
2. Enable the robot with Driver station
3. Type in the number. but don't press enter.
4. Check another dashboard to see if the value changed (I used OutlineViewer)
5. Press enter
6. See value changed in NT and the robot disabled.

Expected behavior
When the user clicks away from the text input (aka the text box loses focus), the new NT value is sent. This is how OutlineViewer handles this scenario.

I don't think sending each keystroke over NT is a great idea, as mechanisms might move per keystroke (like setting a position from 1 to 10).

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Windows
• Version: 2025.0.0 (the season release version)

Additional context
Add any other context about the problem here.

[Gold872]

Thanks for the feedback!

This is actually the intended behavior. While it would be nice to support auto submission from clicking away, it could lead to some dangerous and undesired behavior as you mentioned. For editing values while the robot is enabled, I want to ensure there isn't a way where the user could accidentally submit an incorrect value that could cause dangerous robot behavior, and I think auto submission makes it easier and more likely for those types of scenarios to happen.

As an alternative, there's the option to have a button on the side of a text field that will publish the data when clicked. To show this, right click on the text field, click Edit Properties, and toggle the "Show Submit Button" to be on. Let me know if that resolves the issue.

[scarmain]

I played with this, and it seems to work for our purposes. I will say that it is a little cumbersome to get setup the first time with a lot of potential clicks for a bunch of parameters (like PID controllers are getting to 11 settings each), but I'm guessing the config file would save the option, so it's a one time setup.

Maybe as a compromise, could you have the submit button appear by default on any field that has persistent backing? That could save some of the clicks, and persistent fields are more likely the ones to be edited. (I would say if a dashboard exists, don't change it, but when a new text field is created, check persistent and show box)

[scarmain]

Also, this does lead to a confusing user experience. The user types the field, the value changes on the screen, but the NT value never changed. Maybe you can add an indicator showing change is pending but not sent yet (especially for fields without the send button). Similar to the SendableChooser, maybe just show an ! when data has not been sent yet on out of focus, and nothing when synced with NT.

[Gold872]

Maybe you can add an indicator showing change is pending but not sent yet (especially for fields without the send button). Similar to the SendableChooser, maybe just show an ! when data has not been sent yet on out of focus, and nothing when synced with NT.

I'm currently experimenting with this, however I'm having trouble getting this to work properly when the submit button is shown, since both of them take up a lot of space. Open to ideas on how to arrange these

[scarmain]

Could the indicator be a top right circle, like an iOS notification count? Then it could be a dot too. I don't know if with that indicator, you can also put a hover on it to say why it's there.

[Gold872]

What I could do is have it underline red, as if there was an error with the input, which doesn't take up any additional space

[scarmain]

Make it yellow or some other color, as it's not really an error.

I just thought you can add the exclamation mark to the name/title field, or append it to the side.

[Gold872]

I just thought you can add the exclamation mark to the name/title field, or append it to the side.

The title of it isn't in the scope of the text widget, so that wouldn't be possible without a lot of modification, which isn't something I want to do. I think the easiest option is just to have the default error underline, I think red is a more recognizable color for this type of error

Here's what it would look like