-
-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Binding.oneWayToSource #55
Comments
This is indeed a problem if you use I haven't tested, but I think setting Another quick solution if you don't need to update anything as you type, is simply to remove |
Note that there's a big difference between Debug and Release modes, particularly if you have any kind of Elmish.WPF logging turned on ( |
It appears setting the binding mode to |
Hello,
When working with textboxes in WPF, I continue to come across an issue. If I am typing too fast in a textbox control bound like so:
Then there comes an issue where the Elmish.WPF is still updating the UI in the backend while the user is still entering data. What this means is, the users' caret goes to the beginning of the textbox, causing them to "type behind" the newly updated text. For an example of this issue, you can type quickly in the NewWindow sample.
I feel that the solution is to support
Binding.oneWayToSource
, which would mean that the code behind has no impact on the view (as there is no point to it anyway). Unless, of course, there is already a solution implemented that I am unaware of.In the meantime, assuming that there is no particular reason the view needs to be updated as the user is typing, then a potential solution is to use WPF with InputBindings like so:
Or a command binding attached to a "submit" button.
Thoughts?
The text was updated successfully, but these errors were encountered: