Some people might be wondering why I said that the last two Programming posts were part of a series — after all, the first one was a utility class to help out with type conversion, while the second one focused on using enumerations in the UI. How is that a series? Well, it’s this post which should help to tie everything together.
I mentioned in the last post that a significant drawback of the technique presented there was that it presents the internal names from the code directly to the user. Sometimes that’s ok, if you’re writing something for internal use, or if the names are short enough (a single word) and intended for an audience that speaks a single language. But that still eliminates a lot of potential usefulness.
As a reminder, the (somewhat contrived) example from the previous post went something like this:
<window .Resources> <objectdataprovider x:Key="ReportTypes" ObjectType="{x:Type System:Enum}" MethodName="GetValues"> </objectdataprovider><objectdataprovider .MethodParameters> <x:type TypeName="app:ReportType" /> </objectdataprovider> <app:reporttypesconverter x:Key="ReportTypesConverter" /> <datatemplate DataType="{x:Type app:ReportTypes}"> <textblock Text="{Binding Converter={StaticResource ReportTypesConverter}}" /> </datatemplate> </window> ... <combobox ItemsSource="{Binding Source={StaticResource ReportTypes}}" SelectedItem="{Binding ReportType, Mode=TwoWay}" />
But the ReportTypesConverter isn’t very satisfactory there — it requires specific code to be written for each enum type for each set of different text you want to provide (which can potentially mean that in some cases you’ll need more than one converter for a single enum type, if it’s used in different contexts where you want to use different text). And something just feels wrong about putting something so fundamentally UI-related as what text to display in the combo box in the code of a converter class rather than in the view itself.
So I went looking for a better way. Continue reading A Tableau of Conversion



Recent Comments