I am in the middle of preparing an internal presentation on WPF/Blend and VS and figuring out what developers need to know about the tools.
One thing is clear, developers need good business examples showing the benefits of using WPF and blend so they can take them to their boss and get support for a new development approach. It seems that if we have a rotating cube with video on the faces this does not always get traction with your development managers. Go figure!
So what are the things we need to know as developers about building apps like this? Probably the first thing to get a handle on is overall architecture. A good framework to work in is the old Model View Controller pattern. This is old - dating back to Smalltalk 80 but it is even more relevant today than before especially with WPF.
The basic premise is that a piece of code is in one and only one of three functional categories.
Model – this handles the data model for the presentation tier of the app. It deals with business domain entities like Patient, Customer and so on. Note that this is not the data layer on a multi tier application. To talk to data we need to go through the Model to access business rules and finally data access – but the model is the representation of data that we need at the surface.
View – these are the view elements that we put on the page – more later.
Controller –There is low level Controller code and higher level stuff. In the old days we had to wire up the event handling chain ourselves so that when you click here some piece of code is executed there. Now much of this low level routing is handled by the OS – ultimately by some WinProc in Win32/Win64 code. Higher level stuff we still do by hand, for example in winforms code when we add an event handler to a button click we are writing Controller code.
We have had frameworks in the past for developers to hook into this MVC pattern. Well we had one framework in MFC which used an MVC variant called Document/View. In this framework you still occasionally called Controller code for example calling UpdataAllViews on the Document object is effectively giving the framework a kick to ‘Control’ the view elements.
In Winforms however we don’t have any default MVC or any other architecture pattern out of the box. Take this piece of code:
Public void OnClick( object sender, ....)
This.textbox1.text=Patient.Name;
...
Our Winforms code is littered with this stuff. What we have here is model code (Patient.Name) view code (Textbox1.) and controller code because we are pushing data around the view elements. Of course things get a little better with CAB and software factories – but out of the box the architecture is pretty dreadful.
Now look at WPF. What you create in markup is mostly View Code, with some Controller code when you assign an event handler. The View code is interesting because it has an imperative code behind that you write in C#/VB.Net. When you write CLR classes to add to the datacontext you are working in Model code. Same thing when using converters – mostly model code and certainly no controller code. So out of the box we have a pretty clean separation of along MVC lines. Until that is we start getting sloppy.
Like your old woodwork teacher said ‘Let the saw do the work’ you need to let the framework do its job, especially handling controller code. So imagine that you want to capture some ink in a canvas, recognize the text and push it into a textbox. How would you do it?
From your winforms days you would probably set up a handler for the LostFocus event and write some code and then push the result into the listbox. A basic soup of model view and controller code, highly brittle and difficult to reuse. (If you can have brittle soup).
Try this instead:
1. Create a converter that take a strokes collection and converts it to text.
2. Bind the textbox.text property to the strokes collection of the InkCanvas via a the converter.
3. Feel really good about yourself
You use the InkAnalyzer object that you can get from the Tabletpc SDK. Also add a using statement for System.Windows.Ink;
class StrokesToTextConverter : IValueConverter
{public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
{
InkAnalyzer analyzer = new InkAnalyzer();
StrokeCollection strokes = (StrokeCollection)value;
if (null == strokes) return "";
if (strokes.Count == 0) return "";
analyzer.AddStrokes(strokes);
// Perform synchronous analysis
AnalysisStatus status = analyzer.Analyze();
string message = "";
if (status.Successful == true)
message = analyzer.GetRecognizedString(); }
else
{ message = "Analyze failed" }
analyzer.Dispose(); // Required to free unmanaged resources
return message;
}
public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
return null;
message = analyzer.GetRecognizedString();
message = "Analyze failed"; }