I’ve spent a bit of time today with Whidbey for a small internal project I’m building. I’ve been too damn busy to really sit down and get much done with it and any time I’ve been wanting to do something cool it turns out that the feature is broken or not properly configured on my box…

I got a chance to fart around with new Windows Forms designer and I must say that it is NICE. The editing features and auto-alignment features in the editor make it sooo much easier to get stuff onto forms. This actually makes putting the UI together pretty quick. Since I last tried Whidbey (one of the Post PDC builds) it's also gotten a lot more stable. I worked all night and I didn't loose any forms... <g>

The databinding features are also interesting – the new DataConnector class acts as a wrapper around the 1.x style BindingContext. While it’s not quite as easy as I would like to see it (what is it with these intermediate binding objects anyway? Can’t controls automatically register with it if certain properties are set?), the UI they have whipped up to hook up the databinding is pretty slick. The process goes like this:

• You create a DataContainer
• You point it at a data source, which can be either a DataSet/DataTable/DataView or
  any plain ,NET object
• With the DataContainer defined you can now hook up controls and map properties to fields/properties/columns etc.

The DataContainer acts sort of like a mediator between the form, the control and the underlying data sources. It looks like you need one DataConnector per data source, which can get messy quick if you have a lot of tables or entity objects to deal with (actually with entities you can get by view nesting so this is easier!). On the other hand it makes it perfectly clear where and what you are binding. The DataConnector is a class of course and it fires binding related events that you can check for error handling and other binding related operations. Using a separate object makes sure you’re isolating your binding logic related to a specific item you’re binding in one place. I still think this is overly complex for the simple task of databinding, but it’s a huge improvement over V 1.1 and certainly something that is workable out of the box.

It’s going to take some time to figure this all out however. There are nuances to the DataConnector and the properties you set on each control to set up the binding. For example, you can set different properties for displaying and reading data. So you could write one value to the displaytext of a combobox and retrieve a the selectedItemValue for reading the data back out.

I ran into one snag already – the default is for each control is to unbind only on validating the control, which is a problem if the control doesn’t lose focus before an action occurs. For example, if you click on a menu option or you close the form there’s no validation event that occurs and so the control doesn’t unbind. You can change this option so unbinding occurs whenever a change is made to the underlying data (more like TextChanged operation). This fixes the problem, but this still leaves you with a potential problem when exiting a form or clicking on a menu because the control never validated. This behavior really is problematic because if the control can’t validate you will not get an error, but you can’t exit the form. Unless you handle the error events or use an error provider you get the silent treatment which is really ugly.

I tried to get around this with an old FoxPro trick to just re-focus the control (or reassign the value), but this doesn’t appear to work here. There apparently is no way to force the control to unbind explicitly via. This is a major omission if it turns out there’s no way to do this – it’s possible that it can be done and I’m just too ignorant to find it. I tried though <g>…

Along the same lines I have some problems with a combo box that contains a couple of values. The control is bound old style from a DataTable that holds a cached customer list with a DisplayMember and ValueMember and set up in code. The control is then bound to an entity property that is tied to the ValueMember. IOW, this basically uses two kinds of databindings on the same control.

Something isn’t working quite right here though - the binding of the data works fine, but for some odd reason the listbox control accepts a value, you can tab off then make a change to another field and then looses its value <g>. You go back in tab out again, and THEN it keeps its value. Really odd behavior. Ah, the joys of working with beta… to fix this issue I took off the databinding and manual

On another note, I’m really starting to like the Whidbey IDE. There are a few features that I already miss when going back to VS.NET 2003 which are the debugger Code Inspectors ( you don’t know how much time this will save! ) and Code Expansions. The Debugger Visualizers are smart tags for your debugger and let you see data much more visually than before. Some of the really nice ones even though they are simple are the text viewers which let you view text as plain text in an editbox, or as HTML or XML. The DataSet viewer is also very nice and just having the icons associated with the drilldown topics is super nice.

Code Expansions are script expansions much like Fox’s _FoxCode expansions. They’re powered by XML scripts in the  VC#\Expansions folder. There are expansions for a ton of common things provided. One that I use all the time is the property expansion one. I changed mine around a bit from the default that comes with VS:

<Code Language="csharp" Format="CData"><![CDATA[

        public $type$ $property$

          {

                   get { return _$property$;}

                   set { _$property& = value;}

          }

          private $type$ _$property$ = $defaultvalue$;

          $end$]]>

          </Code>

What’s nice is that VS Editor automatically jumps you to each of these variable names so you can edit them by tabbing through. When you’re done you press Enter and the editor expands all of the expressions. Very cool.

Unfortunately this is only a macro interface, not a script driven interface so you can’t run any code in response to expansions, but still this goes a long way towards alleviating some repetitive typing.

One thing I can’t figure out is how to add new expansions. Each of the scripts is a file in the directory but there must be some sort of master list/index that defines the keywords, but I haven’t found that yet…

Overall the Whidbey editor just feels a lot smoother than VS 2003 and it’s a lot nicer to look at as well. But you can see all the little touches and usability enhancements for most tasks. Now if this stuff only got a bit more stable and wasn’t changing with every build… <g>

I haven’t poked around new stuff in a while and this is a good way to kill a night <g>… Killing it is right - when I look at what I accomplished in real work it's next to nothing. I woulda been done in a half an hour with this code in 1.1, but checking out the new features and seeing what goes on behind the scenes is time consuming as heck. Now it's 4 in the morning, hmmmm... I need to get out more I think.