|
|
Wednesday, June 20, 2007 - Posts
-
A CSLA .NET user, Aaron Nottestad, has been helping test 3.0 and ran into some issues when using the new WPF CslaDataProvider with editable objects. Thanks Aaron! As a result, I had to do some work with CslaDataProvider, so it can manage the object’s entire lifetime from create/fetch through to save/cancel. If it can’t manage the lifetime, especially the save, then it can’t get the new object that comes back as a result of save. And if it doesn’t get that new object, then neither does data binding, so the UI controls end up editing an old instance of the object. So the CslaDataProvider now has Save() and Cancel() methods that you can call to trigger saving or canceling of the business object. Also, as the object is created/fetched CslaDataProvider automatically calls BeginEdit() on the object. This behavior is all optional, and is controlled by the ManageObjectLifetime property of the CslaDataProvider control. So if you want this behavior, you have to set that property to True. If you leave it at False (the default), then you must manage everything through code – though honestly you can’t manage editable objects through code while using CslaDataProvider. So maybe I should make the default be True? Hmm. Anyway, this was easy enough to do and worked great. The resulting forms had exactly 4 lines of code – 2 to call Save() and 2 to call Cancel(). It occurred to me that there must be a way to avoid writing those 4 lines of boring code, and Aaron put me onto the RoutedCommand concept in XAML. A RoutedCommand allows a control like a button or menu item to invoke a method on another control – purely through XAML. There are many examples out there about how this works to create standard Copy/Paste menu items that run against the current TextBox control, and that sort of thing. But none that I found which routed a command to a data provider control. The reason turns out to be that the target of a command must be a UIElement, and data providers don’t inherit from that base class. Oops… I thought I was stuck, because I really do want to route the command to CslaDataProvider in this case. However, I figured out a solution. CslaDataProvider now has a read-only CommandManager property. This property exposes a “command manager” object which does inherit from UIElement and which does handle the Save and Undo routed commands. When it is created by CslaDataProvider, it is given a reference to the CslaDataProvider control, so it simply delegates all Save commands to the CslaDataProvider.Save() Read More...
|
-
I’ve been spending some quality time with WPF and Visual Studio 2008 Beta 1 (Orcas) over the past few months. A couple observations I’ve made: Observation ichi: Putting code in a Page/Window constructor is bad. Yes, I know it is the “C# way”, but it is bad. The “VB way” of putting code in the Loaded event handler is better. Why? Because any exceptions thrown in the constructor prevent the page/window from loading at all, and you have to catch those exceptions in the code that is creating the page/window. In many navigation scenarios you can’t catch them, so the user gets an ugly WPF exception dialog. However, if you do all your init work in the Loaded event handler, the page/window instance already exists. Navigation has already happened, so the “calling code” is no longer responsible for your page/window going haywire. Instead, you can actually handle the exception and show a nice dialog, explaining to the user what happened, and you can (if desired) navigate somewhere else or whatever. Observation ni: Handing control events with += or AddHandler is superior to using WithEvents/Handles. Yes, I am a strong advocate of WithEvents/Handles, and it is one of the major missing features in C#, but for WPF it turns out to be a negative. Why? Because the Handles clause links the name of the control to the code behind. The AddHandler or += approach, while less attractive in many ways, only couples the event name to the code behind . In other words, when using Handles you get code like: Private Sub Button1_Click(ByVal sender As Object, ByVal e As EventArgs) _ Handles Button1.Click While the AddHandler approach results in this code: Private Sub SaveData(ByVal sender As Object, ByVal e As EventArgs) The value of the second approach is that any control can route an event to SaveData(). It doesn’t have to be a button, much less Button1. It actually doesn’t even have to be a Click event. It could be almost any event. The result is that the Presentation (XAML) is less coupled to the UI (VB/C# code) this way than when using Handles. Unfortunately the Handles approach is more explicit and thus more readable (which is why C# should really get the Handles feature), so we’re left trading readability in order to gain loose coupling… For more information go to www.lhotka.net . Read More...
|
-
Slim pickings today. CLR/.NET Scott Hanselman provides advice on how to partition your app and figuring out the right number of assemblies/libraries WCF/BizTalk Services/WCF Dennis points out that he and John Shewchuk recorded a channel9 video that describes the why and what of BizTalk Services. Its now online here: http://channel9.msdn.com/showpost.aspx?postid=317646 Durable Instance Context sample (via Harry ) Windows Vista Running a dual-monitor setup with Windows Vista Resharper/Software Development Tools Took goodness Jeff Palermo found a hack to make Ctrl-N type discovery work properly (speed up!) in Resharper. Ctrl-N I am finding, is one of the keys to success with Resharper. Technorati Tags: CLR , Microsoft , Microsoft .NET , New and Notable , WCF , Windows Communication Foundation , BizTalk Services , Resharper , Windows Vista Read More...
|
|
|
|