Prove WPF and WinForms binding in production form scenarios: submit success and visible errors

[KaliCZ]

Every strong type carries its converter as a [TypeConverter] attribute on the type itself, so any framework that resolves converters through TypeDescriptor binds two-way with no package and no registration call. This issue originally tracked extending that to more UI frameworks; it is now refocused (see the discussion with @drventure below) on proving that WPF and WinForms actually hold up in a production scenario — a real form with a submit action, where a successful submit commits strong-typed values and invalid input shows a visible error to the user.

What's already proven

Binding mechanics, on isolated TextBoxes:

Framework	Suite	Covered
WPF	StrongTypes.Wpf.Tests	Two-way binding; invalid input leaves the source untouched and raises Validation.GetHasError; recovery on the next valid input; culture; nullable properties
WinForms	StrongTypes.WinForms.Tests (#127)	Two-way binding; invalid input leaves the source untouched and fires BindingComplete with BindingCompleteState.Exception; culture (FormatInfo ?? CurrentCulture — the opposite default from WPF); nullable properties

What's not proven is the part the user actually experiences: the tests assert the programmatic error signal, not that the error is presented on screen, and no test exercises a submit flow. Only the positive path has been checked by hand.

Remaining work

For each framework, build a small but production-shaped form — several strong-typed fields (e.g. NonEmptyString name, Email, Positive<int> age) plus a submit action — and test both paths end-to-end:

Success path

• Fill all fields with valid input and submit.
• Assert every value reached the view model as a strong type and the submit action ran with those values.

Error path

• Enter invalid input (whitespace name, malformed email, 0 age, non-numeric text) and assert:
  • the source property keeps its previous value;
  • the error is visibly shown the way production apps show it:
    • WPF — the default ErrorTemplate adorner is applied to the offending control, and Validation.GetErrors(...) carries the message the user sees; pin down what message the TypeConverter exception actually produces on screen;
    • WinForms — an ErrorProvider shows the error icon and text on the offending control, wired the way a production form would wire it (BindingSource / BindingComplete);
  • submitting while an error is pending does not commit the invalid value — define and assert exactly what happens (submit blocked vs. stale value submitted);
  • correcting the input clears the visible error and a subsequent submit succeeds.

Document the answers

• The converter throws on invalid input, so the per-field error message is not configurable. Confirm what text the user actually sees in each framework and document it in the readme's WPF/WinForms sections, including the escape hatch for custom messages: bind to a string property and map to the strong type yourself.

Related, outside binding

DataAnnotations validation attributes compose with strong-typed properties ([Required], [MaxLength]/[MinLength]/[Length], [RegularExpression], and since #126 plain [Range]); details in the comments below.

Deferred — other frameworks (implement on request)

• MAUI — two-way binding cannot work via [TypeConverter] at all: the target → source path converts with Convert.ChangeType only and never consults converters (verified empirically against headless Microsoft.Maui.Controls 10.0.80 and cross-checked in the MAUI source; display works for every strong type via the implicit-to-string operators / ToString). Support would mean a StrongTypeValueConverter (IValueConverter, string ↔ strong type via Parse / ToString) in a potential Kalicz.StrongTypes.Maui package, plus a headless test suite (the plain net10.0 TFM restores without the MAUI workload; the rig needs a small IDispatcherProvider stub because bindings look up a dispatcher on source property changes).
• WinUI 3 / WinAppSDK — not investigated; a XAML markup compiler plus a WinRT type system, needs its own validation pass.
• Avalonia — not investigated.

[drventure]

The bindings look really interesting and useful but how do StrongTypes work in conjunction with existing validation functionality (specifically System.ComponentModel.DataAnnotations ValidationAttribute)?

I didn't see anything mentioned in the source. Just wondering how or if they could coexist.

For instance if you have a string property that can't be null (so in DataAnnotation speak, it would be tagged [Required]), would the validation infrastructure in .net be able to validate such a concept?

[KaliCZ]

@drventure Ha, so you're not really asking about strongtypes, but whether data attributes prevent nulls in the context of desktop apps. I don't know. I'd have to check to be honest.

Generally speaking, you can use StrongTypes together with data annotations. I believe I have an example of that with a NonEmptyString and a max length attribute - ASP will validate it and it will get into OpenAPI. Whether this works for desktop apps I don't know, but should be easy to check.

[KaliCZ]

@drventure So I tried it and yes, the data annotations work in general. [MaxLength] / [MinLength] / [Length] and [RegularExpression] work on NonEmptyString, and [Range] works on the numeric wrappers (as of #126 the plain [Range(1, 100)] form too - without specifying the specific type).

There are some that don't work. For example [StringLength] only works on string, not NonEmptyString and Email. But even in WPF and winforms it shoud work fine.

[drventure]

That's good, but then, I guess I was thinking that part of the point of StrongTypes was that those kinds of validations would be part of the StrongType classes themselves. Ie a class that's essentially very much like email, but with a min and max length, or with a REGEX pattern as a validation, such that if the value being set in wasn't parseable according to those rules, then it'd be thrown out, much like the current email class does.

But it raised the question in my mind.... If an invalid value is prevented from even being set into the class, how would any validation scheme work for it (such as winforms or wpf where if a value is invalid, we want to be notified and notify the user on screen.)?

I'll just have to play with it a bit more i think. I love the idea in general, just trying to figure how it'd fit in with everything else.

[KaliCZ]

@drventure You're right about the length and regex - that is the intention. Although I expected this need to first start with the other types - e.g. numeric types already have a PR for bounding them to a specific range. But this must come to strings as well.

I believe the binding simply throws an exception when using the TypeConverter, so that the error would get shown to the user. (meaning you can't configureit) However you're right, that I haven't tested this myself. I only tested the positive cases.
If you'd need to configure the error message, then you'd still need to first bind to string and then map it yourself.

Let me actually change this issue to make sure that thing works well rather than extend. Winforms is covered now and Maui can get implemented later on request.