My intended solution for this is actually to make CslaDataProvider use an interface instead of a concrete type to interact with the dialog.
In other words, rather than supporting subclassing of ErrorDialog - my plan is to allow you to create your own control that implements IErrorDialog - so you can do whatever you'd like to do.
It is in the wish list - but I haven't gotten to it. Mostly because my focus switched to the MVVM support, which is where I think things are going in the future. I think the data provider idea was good, but clearly it isn't where Microsoft is heading any longer.
This is most obvious in the fact that the VS10 designer doesn't use data providers, but instead uses a super lightweight collection view object to wrap either the data object (business object) directly, or a viewmodel object.
The designer can sort of work with the SL CslaDataProvider, but can't handle the WPF data provider model at all from what I can see...
So at the moment I don't have a good answer for you, sorry. But from a strategic perspective, switching CslaDataProvider to use a new IErrorDialog interface instead of the concrete type (we're talking about a small code change here actually) would allow you to use any IErrorDialog control of your own design.
OK, I didn't like not having an answer, and the code changes really are/were minor.
If you look in svn (3.8.x) you can see the changes - new interface (in the .NET side, linked to SL) that is implemented by the ErrorDialog controls and used by CslaDataProvider.
You can grab the 3.8.3 code directly from svn
http://www.lhotka.net/cslanet/Repository.aspx
Or just make the changes based on the code by hand - they aren't extensive.
The point is that with these changes you can now implement your own IErrorDialog to do whatever you'd like. You could even make the form be the IErrorDialog if you wanted to display the results directly in the page content, etc. Total flexbility is now yours :)
Copyright (c) Marimer LLC