10 Good Things and 10 Bad Things About Silverlight 

10 Good Things and 10 Bad Things About AIR

One omission, in my mind, from the list of bad things about AIR, is the lack of a decent IDE.  I've tried to mess around with it... and it seems that most people use Dreamweaver?? (I could be wrong on this -- would appreciate correction in comments if so) 

Dreamweaver is nice enough for webby things, but it lacks the single most important feature of a grown-up IDE: Intellisense!!!

I may lose mad 1337 points for so saying, but I find the act of programming without code-completion to be almost barbaric.  Code flows much more quickly when you have properly working Intellisense.  I say "properly working" because I used to use Eclipse 3.1, which would routinely freeze when it tried to bring up the code completion menu after an object with a lot of methods or fields in Java.  VS rocks out w.r.t. fast, powerful code completion.  I've seen others do it well, but not well enough.  I'm interested to try the Komodo IDE for Ruby -- haven't gotten there yet b/c it costs a couple hundred bucks that I haven't got to spare right this second.  I stand corrected -- I'm now told the free version of Komodo does in fact have code-completion.  Looks like I have a new tool to mess around with tonight.  I'll have to blog about it later -- I'm currently trying to learn a lot of Ruby so I can make a cool SL - IronRuby project, though I have no idea what that project should be.

To me, code completion is the best way to pick up and run with an API or language with which you aren't intimately familiar.  There's no shame in that -- a good programmer should be able to sit down and hack away at a completely foreign language with some success, provided the API is well-written.  As you get more familiar with the language, CC becomes a way to save a few keystrokes.  Good code (at least nowadays) often has very long method and object names, theoretically to make it more descriptive and hence easy to use.  I routinely type "myObject.xxx...", adding the first few letters of my method name, then strike the down key and enter, saving me the rest of the method name.  My productivity is increased, and the waste of what I consider "stupid memory"** is avoided. 

Sometimes the IDE can make the language.  Maybe I'm just not old-fashioned enough, but that's another story.  I'm a fan of Silverlight, but that's to be expected from someone who used to work on Expression Blend.  The Olympics coverage online is great. 

My only complaint with the Olympics coverage is not with Silverlight, but with the NBC layout.  Why not have all recorded events laid out simply in a list, organized by event?  I want to watch the soccer games, including some of the older matches that I missed (if I can avoid seeing the score), but it is a pain to figure out where to go to get the video to come up.  Some of the older matches aren't even available.  I know demand might be low for those games, but it doesn't seem to me that the cost of making them easily available would be high.  They do have some old games up, but not all.

I also found an interesting speculation on whether or not Silverlight was "evil," very much related to the Olympics coverage, here.

Anyhow -- enough ranting.  Micmcd out.

** Stupid memory: Waste of human memory on things that are more easily automated and don't cost the human much not to know, provided they are using a modern system.  Perfect API memorization is one of those, IMHO.  A programmer should have an idea of what objects can and cannot do, but memorizing the exact spelling of the methods?  It's a waste of perfectly good brainspace.

WPF has a sadly unavoidable memory leak related to data binding, and the problem is greatly exacerbated by Blend.  For specifics, you can look at http://blogs.msdn.com/jgoldb/archive/2008/02/04/finding-memory-leaks-in-wpf-based-applications.aspx .  The leak isn't an awful oversight by the WPF team -- it is caused when databinding to any CLR object, and most data sources stick around for the lifetime of the app, so it isn't regarded as a horrible thing to hold onto (the memory is released when the app is closed).  In Blend, however, if you don't play by very specific rules you can leak the entire visual tree every time you make a change, such as when you go to edit a template, build, make an animation, and many other cases.  In each instance, Blend is making WPF's quasi-mistake over and over.  With a decently sized project, it is trivial to get Blend to be using upwards of 1GB(!!!) of memory simply by making repeated edits to a template.  Blend rebuilds data sources quite frequently when making certain types of edits.  I stumbled upon this issue quite accidentally.

How to fall into the trap:

You have a ListBox in your project bound to an ObservableCollection<MyClass>.  You're quite happy with yourself for using an OC rather than a List, and now whenever you add another instance of MyClass to the OC, you see it in your listbox.  You have a TextBox, however, whose data context is bound to the selected item of the listbox.  The textBox's text is bound to the Foo field of the Data Context, which is a MyClass.  You wouldn't ordinarily think that you'd need to have MyClass know anything about databinding, or to implement any wacky interfaces or anything of the sort.  Maybe the Foo field can't even be changed, only displayed -- so why bother implementing INotifyProperyChanged? 

What happened:

There is an issue where WPF checks to find things that implement INotifyProperyChanged.  If there is a databinding to something not implementing this interface, then it makes a record in a global table.  That record doesn't get cleaned up, as WPF has no way of checking when that DB record is no longer needed.  Everything could work perfectly in your app when you run it, but if you make certain kinds of edits in Blend on the project you can leak memory like... hmmm... like a wet diary?  Did that simile work?  Anyhow...

To Fix:

Anything involved in a databinding should implement INotifyPropertyChanged.  You don't have to raise the PropertyChanged event if you don't particularly feel like it, but to avoid the leak you have to implement the interface.  The annoying side effect here is that it can lead to lots of squiggly green lines in Visual Studio nagging you about declaring an event you haven't done anything with (you have to declare the PropertyChanged event to implement the interface), but this doesn't hurt your code (other than aesthetically).  Add a few lines of useless code, and you won't have to deal with an incredibly sluggish Blend.

Note that, in order to avoid the memory leak you just have to implement the interface.  If you actually want to use it, you need to make calls to NotifyProperyChanged as I mentioned a while back (http://blogs.msdn.com/micmcd/archive/2008/01/22/inotifychanged-magic-also-of-the-black-arts.aspx). 

Situation: You have a ComboBox on your application that changes some major setting, and you'd like to pop up a MessageBox to the user to let her know she's doing something big and to verify the action whenever she changes the SelectedItem of the ComboBox.  In fact, if she decides against it, you undo the change.

(Bad) Solution:

EssentialDataGrouping edg = (EssentialDataGrouping)this.DataContext;
Universe old = edg.CurrentUniverse;
Universe temp = this.UniverseComboBox.SelectedItem as Universe;
MessageBoxResult result = MessageBox.Show("Change current universe?  Changes will be saved to this universe.", temp.ToString(), MessageBoxButton.OKCancel);
switch (result)
{
    case MessageBoxResult.OK:
        edg.SaveUniverse();
        edg.CurrentUniverse = temp;
        this.currentUniverse = temp.ID;
        break;
    case MessageBoxResult.Cancel:
        this.changingUnivese = false;
        this.UniverseComboBox.SelectedItem = old;
        break;
    default:
        break;
}

Problem: The SelectionChanged even fires when you first load the window, so the user gets that confirmation box before the app starts.  Also, if she chooses to cancel her change, the event gets fired again, since you are actually changing the SelectedItem...

(Better) Solution:

Your warning code needs to be put in a separate private method, whose input is a bool that basically decides whether or not the logic should be run.  What you really want to do is run this logic whenever the user is trying to change the selection of the combobox, and now run the logic when you change the selection behind the scenes or when the event is fired by setup. 

This can be done by creating a global bool variable that is set to false by default.  The only way the user should be changing the universe is with a mouse click.... so why not handle those events? (Note: if you want the user to be able to use the keyboard as well, you can turn on the global flag when the ComboBox has Keyboard focus and off when it loses focus.)  PreviewMouseLeftButtonDown and MouseLeftButtonUp are the pair you want... set the global to true on PreviewMouseLeftButtonDown and false on MouseLeftButtonUp.  You want PreviewMLBDown rather than MLBDown b/c you want to make sure to turn on the flag before the click.

In the case where you change the selection yourself (when the user chooses to cancel her action), you need only set the global bool to false.  Note that at the end of the method, if you are allowing for keyboard changes, you should check for keyboard focus and change the global flag to true if focused (otherwise you'd cancel and then not check again if the user doesn't shift keyboard focus).

As it has long been my goal in this blog to spell out the details of anything I find confusing or difficult with WPF programming, Blend, or in general any MS tool I find myself using, I have here laid out the steps to create a sample drag&drop implementation using Blend and VS.  It was more painful than I think it ought to be, but it can be made simple if you know what you are doing. 

The application is simple; a window with two listboxes.  Both are databound to different ObservableCollections (see my earlier post on why you should be binding to these instead of Lists) of SampleDataObjects.  I didn't want to bind to lists of strings, even though in this project a SampleDataObject is a dummy class with one field, "Name," that is a string... because I wanted this to be easy to morph into something dragging pictures, files, chickens... you name it.

The key points of confusion, at least to me, come from the fact that MouseDown is not the way to go in a listbox -- clicking an item doesn't fire the MouseDown event... I don't know why.  However, clicking in an area of the listbox that is uninhabited does, and gives you plenty of easy ways to crash your app with NullReferenceExceptions.

My solution... or at least the one that works for me and doesn't crash, may be a bit unconventional.  I find... that using PreviewMouseDown and SelectionChanged at the same time works quite marvelously.  Even more comically, if you allow MouseDown to do your original job, but check for nulls, it makes the behavior better.  Hooray for Hacks.

Once again - this is NOT the greatest coding practice in the world.  Just a hack that worked for me.  I spent a little bit of time talking to the people who implemented D&D functionality in Blend, and though there is a much better way to do this from the perspective of writing good code.... for an app that doesn't need a lot of power, it's an awful lot of mess.

Here comes the science code:

Start with a pretty simple app.  Two listboxes, two labels.  Gray background on the window is for your eyes' benefit only:

Best. App. Ever.

In order to make the listboxes work the way most of us are used to, we need to set the selection mode of both list boxes.  I'm used to being able to select multiple things by holding CTRL whilst I click, but not if I don't.  This is the "Extended" mode, not the "Multiple" mode.  You can set the SelectionMode of a listbox in the Miscellaneous box in the property inspector.

Moving along, we need to throw some code-behind in here, so I'm going to create another class, which I've called MasterDataHolder.  I've found it to be good practice to create separate data structure (DS) classes and never instantiate them if you intend to use WPF databinding (a.k.a. black magic). 

My DS Class, in its entirety:

------------------------------------------------------

public class MasterDataHolder
{

    private ObservableCollection<SampleDataObject> firstCollection;
    private ObservableCollection<SampleDataObject> secondCollection;

    public MasterDataHolder()
    {
        this.InitializeObjects();

    }

    private void InitializeObjects()
    {
        string[] numbers = { "one", "two", "three", "four", "five", "six", "seven", "eight", "nine", "ten" };
        this.firstCollection = new ObservableCollection<SampleDataObject>();
        this.secondCollection = new ObservableCollection<SampleDataObject>();
        for (int i = 0; i < numbers.Length; i++)
        {
            if (i <= numbers.Length / 2)
            {
                firstCollection.Add(new SampleDataObject(numbers[i]));
            }
            else
            {
                secondCollection.Add(new SampleDataObject(numbers[i]));
            }
        }
    }

    public ObservableCollection<SampleDataObject> FirstCollection
    {
        get { return this.firstCollection; }
        set { this.secondCollection = value; }
    }

    public ObservableCollection<SampleDataObject> SecondCollection
    {
        get { return this.secondCollection; }
        set { this.secondCollection = value; }
    }
}

------------------------------------------------------

Recall that my data objects here are of type "SampleDataObject," a class that has exactly one publicly accessible attribute, a string called "Name."  Just wanted to get a little more abstract than a list of strings.

To allow the window to have access to the ObservableCollections, I need to instantiate the DataSource.  I do this in Blend with the "+ CLR Object" button at the bottom right, under the properties palette:

Go ahead and pick out the MasterDataHolder from the dialog that pops up:

Now be sure to set the DataContext property of the Window to the MasterDataHolder you just created:

You can then expand the MasterDataHolder in the data pane (in the projects tab on the right side of Blend) and grab the FirstCollection and SecondCollection objects and simply DROP them into the listboxes (++ sweetness... sometimes black magic is awesome).  Remember to pick that you want them to be displayed by their names when the dialog appears after you drop the object into the listbox.

You want to have the itemssource bound to an ExplicitDataContext (the third tab option when you are databinding), and chose the Name attribute of the appropriate ObservableCollection.

One last thing you need to make things happen is to set the "AllowsDrop" property of the second listbox.  (Note: in my sample app, you can only drag and drop one way.  It's trivial to reverse it to allow two-way dragging).

The simplest way (to me) to drag back and forth arbitrary data is to create a custom mover, which I have done with this DataMover.cs class:

----------------------------------------------------------------

public class DataMover
{
    private List<SampleDataObject> movingData;
    private bool oneToTwo = false;

    public DataMover()
    {
        this.movingData = new List<SampleDataObject>();
    }

    public void SetData(params SampleDataObject[] sdos)
    {
    }

    public List<SampleDataObject> MovingData
    {
        get { return this.movingData; }
        set { this.movingData = value; }
    }

    public void AddItem(SampleDataObject sam)
    {
        this.movingData.Add(sam);
    }

    public bool OneToTwo
    {
        get { return this.oneToTwo; }
        set { this.oneToTwo = value; }
    }

}

----------------------------------------------------------------

It's nothing more than a container for some data that I'm going to dump in.  The advantage to using this approach is that you can put complicated logic in there if needs be.  Not sure if that's bad coding practice or not, but then again, this whole technique (from here on out), is bad coding practice, so who cares?  Note that the OneToTwo bool is really only useful if you plan on dragging both ways.  It's an easy field to check to make sure you don't try to implement a drop when the user was aborting his drag before getting out of the starting box.

In order to pull off a drag & drop operation (henceforth DD) in C#/WPF, you need to call the DragDrop.DoDragDrop method.  Check out MSDN for details; this implementation is rather simple.

The MouseDown event is a logical candidate for a place to put the code, so I added the following to my Window1 class:

------------------------------------------------------

private void ListBoxOne_MouseDown(object sender, System.Windows.Input.MouseButtonEventArgs e)
        {

            this.dataMover = new DataMover();
            if (ListBoxOne.SelectedItems.Count > 0)
            {

                foreach (object ob in this.ListBoxOne.SelectedItems)
                {
                    this.dataMover.AddItem(ob as SampleDataObject);
                }
                this.dragging = true;
            }   
        }

----------------------------------------------------

Not checking for selection here is an easy way to crash the app.  Anyhow, you also need to implement the MouseMove handler.

------------------------------------------------------

private void ListBoxOne_MouseMove(object sender, System.Windows.Input.MouseEventArgs e)
{
    if (e.LeftButton == System.Windows.Input.MouseButtonState.Pressed && this.dataMover.MovingData.Count > 0 && this.dragging)
    {
        DragDrop.DoDragDrop(this.ListBoxOne, this.dataMover, DragDropEffects.Move);
    }
}

Now you also need to implement the Drop event handler for the target listbox:

-------------------------------------------------------

private void ListBoxTwo_Drop(object sender, DragEventArgs e)
{
    try
    {
        e.Data.GetDataPresent(DataFormats.Serializable);
        foreach (SampleDataObject sam in this.dataMover.MovingData)
        {
            if (dataMover.OneToTwo)
            {
                this.dataHolder.FirstCollection.Remove(sam);
                this.dataHolder.SecondCollection.Add(sam);
            }
        }
        this.dataMover.OneToTwo = false;
    }
    catch (Exception ex)
    {
        MessageBox.Show("no dice: " + e.Data.ToString());
    }

}

-----------------------------------------------------

This seems pretty nice.... except that it doesn't work.  Why?  The issue here is that the first listbox doesn't get the MouseDown event.  That event is taken by the selected item, and the listbox itself is none the wiser.

You could implement the exact same code (from MouseDown above) in PreviewMouseDown, which is given to the ListBox, rather than the item.  The issue here is that PreviewMouseDown happens just before the user clicks, so the drag would only grab the items that were selected prior to the click.

Seeing the failings of the PreviewMouseDown event, I was inspired to try the same code in the SelectionChanged event.  This proved almost brilliant.  This failed in the case where you wanted to click and drag the item that was already selected.  Also... if there is only one item in ListBox_One, then you can't change the selection.  That item is stuck.

Here was where the real H4XR brilliance kicked in.  SelectionChanged fails when you want to use the click, but not change the selection (event doesn't fire).  PreviewMouseDown fails precisely when you want to change the selection, but works when you don't.  Hmmm.... SelectionChanged can only be fired after the selection changes, which happens after the click.  PreviewMouseDown happens before the click.  Thus, if both events fired, the SelectionChanged handler would override PreviewMouseDown.  PreviewMouseDown would only be carried out in the cases where SelectionChanged doesn't fire... and those cases just happen to be the ones where PreviewMouseDown works perfectly!  Brilliant!

Only downside to using this combo.  If you click in the empty area below the listbox items and then drag, you still drag over all the selected items (PreviewMouseDown still occurs).  This isn't the end of the world -- there are worse user behaviors and it's an odd thing to do specifically expecting nothing to happen.  You can make the right thing -- nothing -- happen, simply by having the MouseDown handler re-instantiate this.dataMover, clearing anything that PreviewMouseDown gave it (the selection doesn't change, so you don't have to fight that handler).

In summary, both PreviewMouseDown and SelectionChanged on the starting ListBox should read:

     this.dataMover = new DataMover();
         if (ListBoxOne.SelectedItems.Count > 0)
         {

                foreach (object ob in this.ListBoxOne.SelectedItems)
                {
                    this.dataMover.AddItem(ob as SampleDataObject);
                }
                this.dragging = true;
            }   

MouseDown should just read:

this.dataMover = new DataMover();

And the Drop handler should read as above.  Gorgeous.

If this code makes you cringe... well, there's nothing wrong with you.  It probably should do something of the sort.  However, it works, and for a low-power app this might be all you need.

What this can do:

Drag multiple items from one listbox to another in the same window, or at least in the same application.

What this cannot do:

- Drag an item to a specific location in the other listbox - things always show up at the bottom of the list.

- Rearrange items within the same listbox - pretty common functionality, but not universal, and this isn't in any way confusing.

- Drag items out of the application.  I don't really use the parameters of DoDragDrop.

Anyhow, if this doesn't offend your sense of decency, it's a neat trick.  You won't find that in the API.  I suspect I might get a pay cut just for having written it, but some things just need to be told.

Incidentally, I promise this code has never, ever, to my knowledge been used in an actual MS product.  I'm fairly certain it never will.  Even I'd buy a Mac if it did... (unless we used it in Mac Office just for kicks).  Enjoy. 

Oh, and go Jints.  Gotta hate the Pats on Sunday.

I mentioned in an earlier post that a ListBox's ItemsSource should almost invariably be bound to an ObservableCollection<>, rather than a List<>, because ObservableCollection does some magic behind the scene.  Specifically it notifies everybody bound to it that it has changed.  Having found this, reported it here, and implemented it in my app, I merrily went on my way, assuming that my conversion to the ObservableCollection kingdom would solve all of my updating data vs. data binding properties.

Shockingly, this was not the case.  I had an ObservableCollection of CLR objects I call Actors.  An Actor has a Name property.  My listbox was bound to the ObsCol of Actors, and had a data template that instructed it to display the Name of the Actor.  In the course of mucking about with my app, the user is perfectly capable of changing the name of an Actor.  In fact, that's kind of the point of my app.  Thus, I was not happy when, after going through quite a bit of work to get the names to update properly, given appropriate mucking with the right things, that the ListBox display did not update. 

Enter INotifyPropertyChanged.  If you have an ObsCol of CLR objects to which a listbox is down, the fact that the objects are in an ObsCol ONLY means that adding and removing those CLR objects, Actors in my case, are automatically and instantaneously updated in the listbox.  If you display, for instance, the Name field of the Actor, and you then change the name, you are changing something that isn't currently watched very closely.  Going through sufficient mess can in fact change it, but you need to find a reason for the listbox to completely regenerate its data... and this is just a pain.

The solution is to have your class implement the INotifyPropertyChanged interface.  In VS, a simple right click on the word "INotifyPropertyChanged" will give you an option to implement the interface.

What might be slightly confusing to those who aren't Delegate pro's (a perfectly acceptable situation for those who, like myself, were raised on Java rather than C++), is that you don't have to do anything to the code that comes up as follows:

#region INotifyPropertyChanged Members

public event PropertyChangedEventHandler PropertyChanged;

#endregion

All you need to do is create a method that reads:

private void NotifyPropertyChanged(String info)
{
    if (PropertyChanged != null)
    {
        PropertyChanged(this, new PropertyChangedEventArgs(info));
    }
}

Then, whenever you change your "Name" attribute, you need to make a call to

NotifyPropertyChanged("Name");

You can put in any field name for "Name" to notify of it's change.  The Argument to NotifyPropertyChanged should always be a string, and in fact it should be the actual name (As in the text you typed in) of the method you want to call.  Sorry to beat in the "Yeah, you really type the actual method/field accessor name" bit in, but that actually took me a while to believe was anything more than voodoo.

Just another reason I consider all WPF databinding to be the blackest of magics.

One nice way to get this to work (with suggestions from Dante - http://blogs.msdn.com/danteg) is to play games with the Visibility of an object.  Create a new UserControl and make its LayoutRoot a StackPanel with a horizontal Orientation.  Add a label as the first item in the StackPanel.  Then add all of the types of containers you want - textboxes of various sizes, comboboxes, even image containers if you are so inclined. 

Going into the code-behind file, add an enum and a new constructor that takes an argument of that very same type of enum.  Be sure not to delete the default constructor or Blend won't be able to instantiate the object (unless you don't care if Blend is ever able to instantiate it).  This VariableDataContainer, as I have so cleverly labeled mine, is an item added to a ListBox.  When I create the containers, I do so and tell the container what kind of data it will be holding via the enum in the constructor.  The constructor then sets the visibilities of all the inappropriate containers to Visibility.Collapsed, and the right one to Visibility.Visible (this is an Avalon enum).  Ta-da... it now looks like your ListBox is containing various different kinds of objects.

Of course this has the downside of instantiating unnecessary textboxes, comboboxes, and the like, but if you keep the number of containers to a minimum this shouldn't be a horrendous problem.  If your app lags because you are making 5n objects instead of n... your app is a rare bird indeed.  Or just a really powerful one.  Anyhow, my application is not keeping data on every resident of New York, so it works just fine.  Well, the data container works just fine; the app is still under development.

Update: 3/9/08 -- a reader requested the source code for this container, and I have posted a link to it below.  Please bear in mind that the code is not up to production level yet (though it isn't for a Microsoft product anyway), and there are certainly areas that could stand to be improved.

VariableContainer.cs

Let's start out with something pretty simple.

Code Behind (only one file):

public partial class Window1
{
    private SourceFoo mySource;

    public Window1()
    {
        this.InitializeComponent();
        mySource = new SourceFoo();
    }

    private void Button_Click(object sender, RoutedEventArgs e)
    {
        this.mySource.Things.Add("green");
    }
}

public class SourceFoo
{
    public ObservableCollection<string> things;
    public SourceFoo()
    {
        things = new ObservableCollection<string>();
        things.Add("red");
        things.Add("yellow");
        things.Add("blue");
    }

    public ObservableCollection<string> Things
    {
        get { return this.things; }
    }
}

--------------

I have the itemsSource of the ComboBox bound to SourceFoo's "Things" field.

Note here that I had to "Add CLR Object" to put the data source.  Note that in my code, I have instantiated the SourceFoo object, and a Button_Click should add the word "green" to the list.

Go ahead and give it a shot if you like... no matter how many times you push the button, the only colors you'll be able to chose from are red, yellow, and blue.  No green for you. 

Instantiating the Data Source class in code is precisely the wrong thing to do, as I found out the hard way in a much larger application.  When you add a CLR object data source, the object is automatically instantiated for you in a code-behind file you can't change (the g.cs files).  When I gave the command "this.mySource.Things.Add("green")," green was added to an instance of the SourceFoo class, but not the one to which my ComboBox was bound. 

A quick workaround to this is to make a data binding on the button (or the window... works just as well), and bind to the DataContext of the button.  This hooks you up with the exact same object.

You can then change what happens in the code-behind file.

public Window1()
{
    this.InitializeComponent();
}

private void Button_Click(object sender, RoutedEventArgs e)
{
    ObservableCollection<string> fooList = (ObservableCollection<string>)this.AdderButton.DataContext;
    fooList.Add("green");
}

My Window1 class just got a lot shorter.  You always have to cast the DataContext of an item down from object, but once there you have the right SourceFoo to deal with.

Remember to do this whenever you want to interact directly with a data source class.  In my case, I had a source CLR class that was acting as a go-between for my GUI and my database, keeping a fair amount of the data in memory.  I kept stepping through the code in debug, noticing that my Add operation did in fact add what I wanted it to, but when I got out from the object doing the adding, the TabControl didn't have a new tab item.  Moreover, in debug, I could see that my main data class had not been changed, even though I thought I saw it change.  Just as here, I had one copy of it changing... I just had no idea there was an auto-copy floating around, and that there is no need to instantiate anything you plan on adding as a data source to your project.  That one took a while to sink in for me.  Probably child's play for some, but it frustrated the crap out of me when I was trying to figure out why it wasn't working, and I always promise to show you the gotchas as I hit 'em.  I figure either I'll help out a lot of people who are just learning this stuff too, or make myself look like an idiot.  Hey, you win some, you lose some. 

Will the List be changing during the use of the application?  In my application, we see here a list of characters, which is databound to a List in a C# class.

Clicking on the "Create New" button adds a new Character object to the list.  To my surprise, this part of databinding didn't "Just work."  Just another thing that I chalk up to it all being very convenient black magic.  The issue is that there was no change notification going on.  I could tell through debugging that after hitting the button, there were in fact five characters in the list, but the ListBox didn't seem to care very much.... unless I did an action that caused the ListBox to be bound to a different list, and then switched back, at which point I could see my new character.

Well, I could go through the pain of learning how to make listener notifications, but... that's so... so... "Programming HLL 1.0," as I call it.  Well, maybe I should say HLL 2.0, as C is nominally a high level language, but it looks a lot like assembly to my generation of programmers (I have done both, and C isn't nearly as bad as assembly... it just felt that way after going back from a managed-memory language like Java or C#).  I was "born" in the 2.0 langs, where you could pull this kind of thing off and do the notification, but it would be a pain.  Thankfully, I now work in what I call HLL 3.0, and there is a class for just this kind of thing. 

Realizing that, when not acting like black magic, databinding was a powerful feature of WPF, the C# gurus realized that we programmers would love to have a class that "just worked" with this kind of thing. 

I introduce the ObservableCollection.  It acts exactly like a List except that you can't do an AddRange operation, or anything else that manipulates a bunch of objects at once.  An ObservableCollection notifies anybody databound to it of every change.  In the case of my little character list, every press of the button immediately creates a new character and adds it to the ObservableCollection AND the ListBox.

Isn't it just lovely when things work?  My black magic skills have leveled up, methinks.  You won't believe the dark arts needed in my next post...

This particular gotcha has to do with one of WPF and Blend's most powerful features -- Databinding.  Databinding looks like the simplest thing in the world when it works, but when you're stuck on a tricky issue, it all feels like black magic.  This issue isn't as tricky as it seems, but until you know the magic secret.... erg.

The following is a trivial application, but I came across the same issue in my super-secret project (the few details of which I mentioned earlier).  In this sample app, we have two labels and two comboboxes.  The labels aren't necessary to show the issue; they just help for screenshot purposes.

Fantastic.  Now, we want the comboboxes to have a supply of possible favorite colors, and we're going to stick to a list that looks like it came out of the cheapest box of Crayolas you can find (no Burnt Umber allowed).  So we go to the code-behind file and create a list.  My Window1.xaml.cs now reads:

public partial class Window1
{
    public Window1()
    {       
        this.InitializeComponent();
    }

}

public class ColorDataSource
{
    private List<string> colorList;

    public ColorDataSource()
    {
        this.colorList = new List<string>();
        colorList.AddRange(new string[] { "Red", "Orange", "Yellow", "Green", "Blue", "Purple" });
    }

    public List<string> ColorList
    {
        get { return this.colorList; }
    }
}

Now I go back to Blend and build (building in VS won't force Blend to be using the updated files).  Bobby and Timmy are picking from the same list of colors, so I want to bind the itemsource of both comboboxes to the same list.  Why would I want to instantiate two lists?  Such a solution would scale horribly... suppose we were using the expensive crayola box and assigning favorite colors to Bobby and Timmy's whole school.  Anyhow, let's add a CLR Datasource by clicking in the data box on the + CLR Object button.

We can see our new ColorDataSource object in there, so let's use that.  A cool feature of Blend is that you can do databinding simply by dragging and dropping the datasource into an appropriate container!  Grab the ColorList array -

and drop it into one of the comboboxes.  Select the first option, to "Bind ColorList' to 'ComboBox,'" then select your field as ItemsSource (the default) as shown:

and define a data template (pick what part of the ColorList you are showing in the combobox).  Again, the default is what you want:

Do the same thing for the other combobox, and congrats!  You've got two databound comboboxes for picking Bobby and Timmy's favorite colors.

So, we press F5 to test the app, and we can pick Bobby and Timmy's favorite colors.... except... that whenever I change Bobby's favorite color, Timmy's changes to match, and vice versa.  That's not what I want -- is it because both boxes are bound to the same list? 

Yes and no.  It is partially caused by Bobby and Timmy's comboboxes being bound to the same list.  It is also caused by a little property that I never used to pay much attention to before I came across this issue. Close the app, go back to Blend, and select one of the comboboxes.  Now open up the property inspector and take a look down in the "Common Properties" box.  The offending property is that little checkbox, "IsSynchronized."

Uncheck that box, and repeat for the other combobox.  Now that neither of them is synchronized, when you test the app you can do what you wanted to do:

The world is right again... little boys can differ on their favorite colors.  Even if they both picked strange colors. 

The situation: you want your buttons to have a little bit of style.  You're not an uber-artist, but you'd love the illusion of 3D, you want it to act right, and throwing away the default chrome on a button takes away the built-in nice functions.

Start by dropping a button on your artboard.

You end up with this run-of-the-mill, boring gray button.  Edit a copy of the template and delete that horrible chrome.  Of coruse, this leaves you with an empty button, so add a grid (so you can put more than one thing in it), and inside that grid put a rectangle and a ContentPresenter.  The rectangle is your background, and you can do with it as you wish.  I made mine green and gave it nice, rounded edges.  To give the illusion of 3D, give it a BitmapEffect (expand the Appearance properties area), and chose a bevel bitmap effect. 

 The starting position for the button should be up, so chose your EdgeProfile to be linear, and pick a small bevelwidth, like 2.  The effect is subtle, but noticable. 

Now select the Template, and add a property trigger.  The "Activated when" should read target-element.IsPressed = true. 

With the recording active (and it should be now), select your rectangle and go to the bevel property.  Change the EdgeProfile to BulgedUp; the button now looks like something is pushing it down a bit.  I recommend also giving a color clue.  In my case, I made the color slightly lighter. 

Now remember to shut off the property recording, go back to the main project, and build.  The effect is nice, and was simple to create.  You can add another property trigger for IsFocused, though I recommend a more subtle effect, like changing the stroke of the rectangle to a bright color (and thickening it a bit so you can see it), or changing the color slightly.