Lately I’ve been developing standalone WPF applications using Visual Basic. To make a WPF application somewhat easy to maintain and extend it is extremely important to use some design pattern. The most popular design pattern around when developing WPF applications is the MVVM pattern (Model-View-ViewModel).
Developing a single view application is really really straight forward using the MVVM pattern, but when it comes to multiple views application there is no simple solution to update one or more views from another view and still make the Views and ViewModels behind them loosely coupled. When I say update I mean making some property change in the ViewModels behind the Views to be affected by the change of something in another View or ViewModel.
In this post I will show how I’ve solved the problem using events and delegates. Before I describe my solution, please read about the basics in the MVVM design pattern. There are a lot of good publications around, e.g. THE MODEL-VIEW-VIEWMODEL (MVVM) DESIGN PATTERN FOR WPF and Model View ViewModel (Wikipedia).
To make it easier to understand this post and to make it easier for me to write it, please read the following article if you’re not familiar with WPF data binding and the usage of INotifyPropertyChanged: http://coredotnet.blogspot.com/2006/05/wpf-data-binding-tutorial.html.
The other day I wrote about sharing types between web services to simplify implementation of consumers of these services. You can read about it 
In this article I would like to point out a useful way to accomplish something that would be really easy, but still have been annoying me for the last couple of months. Imagine that you would like to get some data of some type from one web service and pass it on to another. The data types on both server sides are the same, but the compiler won’t let you pass the type from the first service on to the next one. Casting won’t work either, not without implementing some kind of home made casting method.
This article presents nothing new at all, but sometimes it is nice to freshen your memory when it comes to smooth stuff available in the .NET Framework. I will give a couple of examples to select, count and look up elements in a collection of objects, both using regular functions and by using lambda expressions. The methods I will use are available when using .NET Framework 3.5.
Coming back from a little break during Christmas I looked around on the ASP.NET web site (
The other day I got a question from a colleague of mine, regarding the XML schema usage when defining a web service interface, like the one defined in series. The question was something like this: “How will the consumer of the web service react if the, from the XSD file, auto-generated class used as in and return parameters is updated?” I couldn’t give a straight answer, other than that I assumed it would be transparent to the consumer as long as no nodes were changed or removed and only new nodes were added to the schema. I decided to give it a try, using a really simple XSD and a couple of really simple web methods. I will give a schematic picture of the scenario that I will test out later on. 
Right after I published the previous post on the spatial data and BLToolkit components I decided to write a follow-up on that post. I wasn’t happy about the way I described the implementation of the new property and field attribute to support the SQL Server UdtTypeName property and spatial data types. I hope I will make it more clear how I accomplished the support for this here. Please read the previous post about this on, .