Question

Seriously, it seems like every time I want to make my UI elements talk to each other, I end up coding a new, custom, IValueConverter :(. Someone tell me that I’m doing it wrong, please!

Examples:

• I wanted a button to be enabled only if my textbox contained a valid URI. Great, time to code up a UriIsValidConverter!
• Oh oops, I also wanted to disable it while I’m processing something. I guess now I need to code up a UriIsValidAndBoolIsFalseMultiConverter!
• I want to display a list of files in a certain directory (specified by a textbox) inside a listbox. I guess I need a DirectoryPathToFileList converter!
• Oh hey, I want icons for each of those files in the listview. Time for a FileInfoToBitmap converter!
• I want my status to be red if my status-string contains “Error”, and green otherwise. Yay, I get to code up a StatusStringToSolidColorBrushConverter!

I’m really thinking this isn’t that much better than the old Windows Forms method of just wiring up everything manually using TextChanged events (or whatever). Which I guess is still an option. Is that what people actually do, perhaps, and I’m trying too hard to make everything fit into the databinding paradigm?

So yeah, please tell me if this is really how WPF coding is—or if I’m doing it wrong, and if so, what I should be doing.

Answer 1

Your approach is perfectly valid (though I would use a multibinding for the second example, rather than a such a specialised converter), though by placing all your logic into the XAML you are producing very high coupling between the way the application looks and the way that it behaves, because of this you may want to look into the MVVM pattern to separate those things out.

Under the MVVM pattern your XAML (the view) just contains very simple data bindings into a ViewModel which handles all the logic and updates the view through the INotifyPropertyChanged interface. The code for your third example may look something like:

public class DirectoryManagerViewModel : INotifyPropertyChanged
{
    private string _directory;

    public string Directory
    {
        get { reutrn _directory; }
        set
        {
            if (_directory != value)
            {
                 _directory = value;
                 OnPropertyChanged("Directory");
                 if (IsValidDirectory(value))
                 {
                     PopulateFiles();
                 }
            }
        }
    }

    public ObservableCollection<FileViewModel> Files { get; private set; }

    private bool IsValidDirectory(string directory)
    {
          //return if the directory exists etc.
    }

    private bool PopulateFiles()
    {
         //Populate Files with files in directory
    }
}

Where FileViewModel is another view model which contains the name and the icon for a file.

The advantage of this approach is that the ViewModels can be reused with other views and other technologies such as ASP.NET or Winforms so you are not locked into the WPF stack. (alos if you work in an environment where there are designers responsible for the look and developers responsible for the behaviour, this helps define those boundaries)

At the end of the day though this logic does need to go somewhere and while there are better and worse ways to architect your application you are still going to be writing code that takes a string and converts it into a series of filenames and icons somewhere.