-
Notifications
You must be signed in to change notification settings - Fork 977
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
Control Binding should use Invoke #8532
Comments
@KlausLoeffelmann would be the best bet to answer this as he has investigated Async functionality in Winforms. |
That's definitely something we should look into, but also very cautiously, as it could potentially break existing scenarios if we introduced it unconditionally. So, if we consider it (and we should), we should think of an opt-in mechanism. |
@KlausLoeffelmann what about an Otherwise, we can check Reference: |
I probably should open a PR for this but I can't pass some Interop tests locally and I can't figure out why. I did some changes to the Binding class. First, I added this attribute: Then, I added a new constructor:
I also added a private method to check for the control data:
And lastly, I made changes to the
Like I said, I couldn't really pass the automated tests but I believe I am at least in the right direction. Does this help you in any way @KlausLoeffelmann ? |
You could open a PR anyway and make it Draft for now. It's a great initiative! - I'll take a look as soon as I can spend a few hours on this - it might take a while, though. In the context of the latest changes in Command Binding, we also got a few pings on Converters for Binding scenarios, so I would need to wrap my head around that as well. https://devblogs.microsoft.com/dotnet/winforms-cross-platform-dotnet-maui-command-binding/ |
One additional thought: What would happen in this case (or what would you expect to happen), if the setter of that property caused an exception? |
I don't think the That's also what I would expect in this case, since this should be setting a value, so it should "just work". Of course, you may have commands, events and everything else tied to this property but even if you do, it's better to handle exceptions yourself in those cases, right? |
@zeh-almeida could you put in a draft PR so we can investigate the test failures? |
~~Yeah, sure! Will do as soon as possible.~~
@elachlan PR opened. Still have to write tests, though.
|
@zeh-almeida, when you're ready to do the official API Review Process you can just edit your first comment to follow their pattern. I would definitely want @KlausLoeffelmann to sign off on a change like this before bringing to the review board. |
@merriemcgaw I created an API Proposal following the template and have linked both this issue and the PR as well. Thank you all for the support, I am excited to contribute to the project! Forgot to ask: Should I publish my PR now? It is still in draft. |
Wait for it for a little while. |
Also please note my comment here: In addition: It would be also nice to have a small WinForms demo app for it, based on the API change of the branch, we're we could quickly test scenarios and experiment with it? Maybe put that in a public GitHub repo and link to it, if you got the time to set that up? |
@KlausLoeffelmann I do have a scenario for it but using current library version. Here's the link to the commit with the code: You can also see a emerging MAUI app using the same infrastructure, they are all using async commands. Regarding your comment: I am not sure I understood correctly, those changes you propose are not directly related to the issue, right? They seem to be directed at the designer, is that correct? |
Yes. But we need to take those Designer issues into account in the decision-making process, because that's an important thing for the/a typical WinForms workflow (designing) process. Also, if we were to modify In addition, I also want of course to have your opinion on the |
Frankly speaking, I would like to have a default constructor for I know this is a very history-rich code but still, if we are talking improvements, I guess this would be a good one. I like the idea of a Could the designer identify the |
The designer points out Binding capabilities for properties on the control side (which properties can be bound to on a control) is a different story: To make a control property like
For the signature changes: |
So I believe using the toolkit already covers the DataSource scenario, since the properties and events are created with the names the designer expects. The only thing missing is telling the designer to bind with invoke. Like I said, I think this should actually be the default behavior. If this can't be the default behavior because of codegen, API or any other braking changes, I think we should add a property in the designer to make it bind with the invoke option set. This way no existing scenarios are broken and if you want, you could use the new behavior without issues. Does that sound feasible @KlausLoeffelmann ? |
Is your feature request related to a problem? Please describe
I have a WinForms application which uses CommunityToolkit.Mvvm for bindings.
I am also using the same MVVM library to build a MAUI application for study purposes.
MVVM allows me to have asynchronous commands and messages, which I use to propagate changes across models.
However, because my form binds some controls to those models, I have started to receive UI Thread exceptions when updating values.
After a lot of debugging, I saw that the
SetPropValue
method in the Bindings class does not use theInvoke
method when updating values:winforms/src/System.Windows.Forms/src/System/Windows/Forms/Binding.cs
Line 956 in 77d01dd
Describe the solution you'd like and alternatives you've considered
It is my understanding that the
Control
property is available for theBinding
object:winforms/src/System.Windows.Forms/src/System/Windows/Forms/Binding.cs
Line 110 in 77d01dd
In this case, I propose that the
SetPropValue
method checks if theControl
property is not null and tries to update it's value through an execution of theControl.Invoke
method, to ensure the value change occurs in the UI Thread.Will this feature affect UI controls?
I do not think so because the underlining flow is kept as is.
The text was updated successfully, but these errors were encountered: