XTab's Blog

  Quite often as I browse through the VB.NET Forums on vbCity I see questions about tasks that can be quite difficult in WinForms, but would be much easier to deal with using WPF. One recent question that fits this description is the following one:

  As you can see, essentially this is a task where a ListBox contains some items that represent numeric values. Some simple arithmetic is used to calculate the value for the third line. The color of the text on that line is decided depending on whether the value is negative or higher than 1000.

  In Windows Forms this job would need the use of OwnerDraw in the ListBox, with each line being drawn using the GDI+ DrawString method. While not that daunting a task, OwnerDraw and DrawString can get a bit unwieldy if you have a lot of data to handle. So, even though OwnerDraw would probably be fine for this particular example, I still thought it was worth seeing how WPF might be used to deal with it.

  With my WPF head on, I first thought that I would tackle this with a value converter using IValueConverter, reading the values and setting the Brush color based on the value. But as it turns out, WPF's innate ability to accept varying settings for each individual ListBoxItem's Foreground property made it a much easier proposition.

The Basics

  Because I'm concentrating on the UI here, not the mechanics of how to get the values, I've short-circuited this part and simply hard-coded the values into the ListBox. (Don't worry, I'll get to how you can take values from the user, insert them into the ListBox and do the arithmetic at the end, if that's something you need.)

  Here's the Xaml to create the ListBox and those three items:

  (I've manually done the arithmetic which is very unrealistic, but keeps the code to a minimum for now)

  Of the various ways of tackling this, I decided to use a simple Select Case block in the Code-Behind. The ListBox control has a LayoutUpdated event, which fires whenever there is a change to the layout of the visual elements of the control. We can use this event to apply the appropriate colors to the text items.

   So if you already have a ListBox with values in it, that's all the code you need. It's quicker and cleaner than the OwnerDraw route, I think you'll agree.

Taking User Input

  As hard-coding those values in the Xaml isn't very realistic, as promised earlier, here is one way to create the ListBox in Xaml and update it in code:

  The result will look something like this

  As you change the values in the two TextBoxes, the ListBox will update and the text color of the third item will reflect the rules in the LayoutUpdated event.

  Because the scenario has a preset configuration of just those three items, the above approach is the easiest.

Varying Number of ListBoxItems

  If for some reason you can't or don't want to create the three ListBoxItems in Xaml, then you can easily (if slightly more verbosely) do this in the code-behind:

  You can of course vary the number of ListBoxItems added in this way and select another of them for the text color formatting treatment. You'll see that I put all the code in the Button click this time. If you're wondering why, it's because the LayoutUpdated event fires when the ListBox is first created. As there are no ListBoxItems in existence at that moment, you will get an exception when you try and access the non-existent ListBox1.Items(2) item.

And Finally ....

  Although it's not part of the original question, you might at some time want to comb through a ListBox like this and change the color of all the lines that meet our criteria of less than zero or more than 1000. Enumerating through the ListBoxItems will do this job for you:

  And as a final thought, if you only want to turn text Red if the value is below zero and leave it as Black for all other values then you can replace that multi line Select Case block with a single line IIF statement.

  For completeness, all the above samples should have some validation added to ensure that the items exist and that the text represents valid numeric values.

First Chance Exceptions

  I suspect that most of us have become so used to seeing the message that reads:-

" A first chance exception of type 'System.ApplicationException' occurred in WindowsApplication1.exe "

 that it hardly hits our conscious thoughts any more.

  But did you ever check out just what this message really means or wonder whether you should or could do anything about it ?

  I suppose the first thing you need to know in order to answer those questions is just exactly what a First Chance Exception is. Well, in it's simplest terms it's a mechanism that flags up that there is a possible error condition. The key point here though is that this flagging up takes place in the Debugger and not in the running application itself. (We probably often think of the two as being the same thing, but in fact that's not really the case).

  When the Debugger detects an Exception situation it raises a First Chance Exception. In several situations it isn't always desirable for the program to come to a grinding halt each time. And of course, being a skilled developer, you will have built appropriate Try Catch exception handling blocks into the code which will sort the problem anyway! So, depending on the Debugging settings you have laid down (more on this later), the Debugger allows this First Chance Exception to pass and the program continues to run.

Second Chance Exceptions

   At this point, where the running program now has to deal with the Exception situation, the application will either handle the Exception or not handle it (your Structured Exception Handling code coming in to play here). If it does handle it, then the application will of course be allowed to proceed and it will happily keep running until the next problem is encountered or the application ends.

  If the program fails to deal with the Exception at this point, the Debugger is notified again of this unhandled error situation - and this is now the Second Chance Exception level. Hitting this point will result in the kind of Unhandled Exception Message Box that I know you will have seen many, many times:

An Exceptional Situation - XamlParseException

  Although I'd never really given it much thought I guess I'd always assumed that by default the settings in Visual Studio were such that all First Chance Exceptions were allowed through to the program as described above. With some timely assistance from the Microsoft Visual Basic team, I discovered recently that this is not the case. There is one Exception which by default is set to Throw on a First Chance Exception - and that is the XamlParseException.

   When I say "by default" I'll have to qualify that slightly. I'm not sure that it is set by default in every kind of installation of Visual Studio 2008, but certainly in the Pro and Express Editions if you have set the Profile to Visual Basic developer settings then this will be the case.

  As a result I spent quite a long time struggling with a particular project that had to deal with many situations where the Xaml at certain points in time was not valid and so would not parse. Even though I had built in a Try Catch block for this Exception, the program would never reach that exception handler because the Debugger would throw the Exception at the first chance stage.

  The route to finding this setting in the IDE is as follows:

Select Debug > Exceptions
then in the Window that appears, choose "Common language Runtime Exceptions" and expand the list.
Navigate down the list until you reach "System.Windows.Markup".
Next click on the plus symbol to show the Exceptions in this class.

  (Alternatively you can click the "Find..." button and enter the name of the Exception).

  You can see in the screenshot below that the "Thrown" checkbox is checked:

 which is of course the reason why my project was stopping in Debug mode whenever it first hit a XamlParseException.

  If you want your code to be allowed to handle this kind of Exception (as I did) then of course you just need to uncheck that box.

  I did a quick sweep of all the settings for all Exceptions and that XamlParseException seems to be the only one that is checked by default. But if you should come across a similar puzzling situation yourself in the future, you should probably think of those Exception settings as one of the places you should first look.