We have a LOB UWP app where clients are working with data and may need to edit text that already exist in a TextBox. We often get complaints that the process of editing a TextBox is slow because the user first has to Click/ Tab in the TextBox to display the clear button and then click the clear button to clear the TextBox. This is very inefficient when working with large amounts of data. It would be far more beneficial if when the users Clicks or Tabs into the TextBox the text could be highlighted ready to be written over.
@Elmarcotoro You can currently type on the textbox when it has focus and it gets appended to the end of the already available text. Ctrl-A, backspace can be used to clear the existing contents if you want to avoid switching from the keyboard to mouse to click on the x button. Are you saying that if focus is on the textbox, when you type we should clear the text and enter new text automatically ?
We have the same issue. We only have 1 UWP app; the others are WinForms. When a user tabs to a textbox in WinForms, the text is already highlighted ready to be typed over.
However in the UWP app the text is not automatically highlighted. The user then has the additional step of having to select the text before editing. The text should be highlighted as it is in WinForms.
It might not seem like much, but it impacts the productivity of business users who work with data all day.
@VagueGit Thanks for clarifying.
This would be a great option to add, but I wouldn't want it to be forced. Perhaps you can add a property for example AutoSelectOnFocus
that would give more control over this behavior.
That does sound like a good idea @yaichenbaum. Given this is the way other UIs work perhaps it should be on by default. That would make it easier for non-xaml devs to adopt xaml
@VagueGit clarifies my point perfectly. I also agree with @yaichenbaum
@chrisglein @MikeHillberg as FYI. I've marked it as needs-winui-3 and put it on the back log.
@ranjeshj Just curious if you are marking it as needs-winui-3 because of the available resources or is there something else that is stopping it that will be addressed with WinUI 3?
@yaichenbaum Both reasons actually in this case. Currently the team is focused on getting the framework code decoupled from the OS in WinUI3. This change would have to be in the framework code.
Most helpful comment
@yaichenbaum Both reasons actually in this case. Currently the team is focused on getting the framework code decoupled from the OS in WinUI3. This change would have to be in the framework code.