Recreate ApplicationPropertyPage in code.

[tmeschter]

This is a partial example of recreating ApplicationPropertyPage.xaml in code. Not all properties are present, and the original file still exists. However, this is enough to understand what a real-world property page would look like when defined in code.

Microsoft Reviewers: Open in CodeFlow

[drewnoakes]

These could be constants on the provider classes.

[drewnoakes]

Some helper methods for this kind of thing could be helpful.

This could be written as:

Suggested change

	new()
	{
	// TODO: EditorType could come from a constant
	EditorType = "LinkAction",
	Metadata =
	{
	new() { Name = "Action", Value = "URL" },
	new() { Name = "URL", Value = "http://go.microsoft.com/fwlink/?LinkID=287120" }
	}
	}
	HyperlinkActionEditor("http://go.microsoft.com/fwlink/?LinkID=287120")

[MiYanni]

As I mentioned on the Teams channel thread, after seeing what code-based Rules look like, I really think these should be generated from the XAML as part of the build instead of being the source-of-truth for the Rules. It isn't very intuitive from people who want to work on the UI and have WPF experience. If we do a hand-wavy generation as part of the build, no one would be none-the-wiser and we'd accomplish the goal of them being code-based instead of loading the XAML file itself.

Additionally, our localization infrastructure works with the XAML files. How would code-based work in a localization scenario? If we generate generate this code, we can generate code for each language when the resources (XLF files) are available.

[MiYanni]

@tmeschter Is this still under active consideration? Might make sense to close this until we decide to revisit the property pages. I also wanted to ask, does this have any added advantages for unit testing scenarios? Like, make them simpler or easier, or make mocking easier. Also, the localization cost for this would take time as we'd have to convert the strings into resources.