XTab's Blog

Object Initializers - A New Perspective

Ged Mead — Thu, 28 Aug 2008 07:09:00 GMT

There's something that's always bothered me a little bit about creating classes. We go to the trouble of creating backing Private fields and Public properties in order to implement data hiding - right? And when we want to include data validation, we usually use properties for that task, don't we?

But then what do we do? We go and create a parameterized constructor that lets client code push invalid data straight into a field. At least that's what I see in most of the class building examples I've come across - both in books as well as in real world code. It's quite rare to see values passed into properties in a parameterized constructor; fields seem to be the most popular recipients of initialization data.

I'm surprised at how many times I've seen this done. Of course it's possible to include validation in the constructor too (but the examples I've seen that use fields rarely seem to do this; leaving the door to bad data wide open)

Luckily, we now have a very easy solution - Object Initializers.

In fact, you could claim that with the arrival of Object Initializers the parameterized constructor has just about become redundant.

Parameterized constructors were devised to make it easy to pass arguments in to a constructor and to avoid having to add several lines of code for property values when initializing a new object. You know the sort of thing:-

Code Copy

Dim sr As New SalesRecord
      sr.CustomerName = "Joe Soap"
      sr.Total = 2399.65
       '  etc  etc

which was short-circuited with :-

Code Copy

Dim sr As New SalesRecord("Joe Soap", 2399.65)

However, as I said, in most cases people code this so that it assigns the CustomerName and Total values directly to the fields.

Object Initializers step round this issue while still enabling client code to be fairly concise. How it works is that when you initialize an instance of a class object you are allowed to use the 'With' keyword as a way of assigning values to properties, all in one line of code.

Let's knock up a quick class to demo this.

Code Copy

Public Class Product

    Private _itemcode As String
    Public Property ItemCode() As String
        Get
            Return _itemcode
        End Get
        Set(ByVal value As String)
            _itemcode = value
        End Set
    End Property


    Private _cost As Decimal
    Public Property Cost() As Decimal
        Get
            Return _cost
        End Get
        Set(ByVal value As Decimal)
            If value > 0 Then
                _cost = value
            Else
                _cost = 0
            End If
        End Set
    End Property


    Private _itemname As String
    Public Property ItemName() As String
        Get
            Return _itemname
        End Get
        Set(ByVal value As String)
            _itemname = value
        End Set
    End Property


End Class

So, three fields, three properties (one of which includes some validation) and just the default constructor. To create a new instance of the Product class and assign values to any of the properties that interest us, this is what we can now do:

Code Copy

Dim P1 As New Product With {.ItemName = "Widget", .Cost = 0.99}

That's it! A Product instance with those values for the ItemName and Cost properties now exists. And of course the validation is applied effectively at the time of instantiation to avoid any unacceptable values being passed.

Note that the property assignments are contained inside curly braces and not standard parentheses.

  There are several advantages to this approach. Not only does it get around the validation problem I mentioned at the start, but it also allows you to pick'n'mix the properties you want to assign values to when you instantiate the object. As you saw in my example above, I chose only to assign values to two of the properties.

   And if that's not enough to get you interested, there's more. You even have the further advantage that you can pass the values in any order you like (unlike the standard parameter arguments which have to be passed in a strict order).

   Finally, if there is a parameterized constructor available that contains some, but not all, the arguments you want to pass in, then you can simply combine the two approaches and use the constructor's parameters, as well as the object initializers, all in one chunk of initialization code.

  So if you had this parameterized constructor in the class:-

Code Copy

  Sub New(ByVal code As String)
        Me.ItemCode = code
  End Sub

you could use the following code to assign values to all three properties:-

Code Copy

Dim P2 As New Product("TOOL12") With {.ItemName = "Spade", _
    .Cost = "12.99"}

How cool is that?

To be honest, I'm not sure how often I'd want to do that - given that I can do the same thing using three object initializers - but it's an option to consider.

So there it is. A new feature that you may have heard about but weren't sure if it was going to be of use to you. Personally, I think it's great and plan on implementing this approach whenever I can from now on.

WPF FlowDocuments and Using WPF Controls in Windows Forms

Ged Mead — Tue, 15 Jul 2008 17:01:00 GMT

I get a reassuringly high number of hits on my WPF blog items, so I guess they're proving useful to a few people out there. So it just occurred to me that I should maybe include a link here in my blog to a couple of WPF articles that I've written recently that are published over on our devCity site that might be of interest to newcomers to WPF.

The first one is an introduction to using FlowDocuments in WPF.

When WPF first came on the scene, one of the features that got a lot of air time was the display of documents. Leading edge projects like the NY Times Reader and the British Library manuscript display raised a lot of awareness of the possibilities. Strangely though, since VS 2008 shipped there doesn't seem to have been a lot of mention of this part of the package. So I thought I'd take a look at how easy (or not) document handling really is in WPF

If you look at it, you'll see that it's Part 1 of what will be at least a two part series, maybe more. Part 2 is written (in my head) and just needs the time to be put down over there on devCity. Hopefully it will be done no later than next month.

(Oh and if you were hoping the examples will stand comparison to the NYT or British Library you'll probably be in for a disappointment, but the articles will enable you to harness the technology at an easy level.)

This week I published an article on something I've been wanting to write about for a while. Using WPF Controls in Windows Forms.

Whenever I see a question along the lines of "How can I include an image alongside each item in a list of items or use more than one font, or use a mix of background colors?" I usually find myself muttering "WPF!". This is a lot more sociable and positive than many of the things I mutter as I sit here each day, but finally I've realised that I need to do something about it.

The result is this article, which works through the steps needed to harness the rich UI features of WPF to the more familiar paradigm of Windows Forms.

The example used will show you how easy it can be to use a WPF control in a Windows Forms application and you can use this article as the stepping stone to creating your own. I've used a WPF ListBox as an example and even the unadventurous one I've created will give an idea of what can be done.

I picked a ListBox purposely as it gives me an opportunity to show how DataTemplates work too.

If you're interested in WPF and want to know more about either of these topics then I hope you'll check out my articles.

How To Navigate Around Your Code in Visual Studio

Ged Mead — Tue, 08 Jul 2008 15:48:00 GMT

One of the things that I've always found a bit frustrating as a project grows larger and larger is that it gets more difficult to navigate backwards and forwards between chunks of code that you've recently accessed.

Now I know that Visual Studio has some built in navigation hot keys:

Ctrl and Minus to go back to the last point,
Ctrl-Shift-Minus to go forward again are the most useful,

but it can still be a bit laborious when you're trying to flit between several sets of code blocks and you don't particularly want to move in a linear or consecutive way.

Step forward that very clever little Add-In (well, not so little really!) CodeSMART. For some reason I'd stopped using it when I upgraded Visual Studios a while back, but when I was looking around for an answer to this problem I remembered that amongst its many little tools is the Code Explorer.

One of the elements included in the Code Explorer window is a history of the last 20 procedures you've visited. So not only can you move backwards and forwards one step at a time, you can of course jump to any of the saved locations just by double clicking on a choice in the list.

It has some smart features (well, it is CodeSmart after all!), one of which is that it greys out any history items from other files - which helps you to very quickly identify those in your current file that you may be looking for.

And best of all? It persists your history list for each individual Visual Studio Solution, so that the next time you access a particular project Code Explorer will be repopulated with the relevant history for that project. How cool is that?

The Code Explorer does have additional features, such as a fast and neat search tool to take you to procedures that match search criteria, together with what's effectively a Favorites store, the Workbench, where you can keep tabs on items you're particularly interested in.

Of course, CodeSMART has a ton of other features and tools, so if you want to check it out you can download a trial version from their website here.

Another Gotcha! - Select Case Using a Range of Integers

Ged Mead — Sun, 06 Jul 2008 17:22:00 GMT

I never cease to be amazed at how many ways you can fool yourself into thinking that your code will do one thing, but in fact it does something completely different. Sometimes the subtlety of the error is so fine that you can spend ages trying to work out the source of the problem and, to make life harder, there's no Exception message to give you a pointer and sometimes even using the debugging tools doesn't lead you straight to it.

I was working on something that kept track of a particular value. If the value was between 31 and 40 then I wanted to display a message. Without thinking too hard about it, I wrote the following code:

Code Copy

Select Case InputValue
            Case 31 - 40
                MessageBox.Show("Invalid Values")
            Case Else
                '  Do something
End Select

So, what do you think? Will this do the job as described?

Actually, no - of course not; otherwise I wouldn't be sat here writing about it, would I? The question is then: What's wrong with it? On the face of it, it seems to check for values between 31 and 40, displaying a message if that case fits. Otherwise, it does something else. But if you were to try this code and enter values between 31 and 40 you wouldn't get to see that MessageBox.

It's one of those Duh! moments as soon as you realise why. Although most of us will have read that as saying "Case 31 to 40" , that isn't how the compiler sees it. Because we are dealing with numbers and because the compiler knows about adding and (in this case most importantly) subtracting .... the compiler reads that as "Case 31 minus 40. So the MessageBox will only appear if a value of -9 is applied to the InputValue variable.

It's not a compilation error, so you don't get any feedback. It's allowable but faulty syntax, so you're not alerted to what is essentially a logic mistake.

So simple when you realise why, but it's another example of those tricky little Gotchas that'll get ya if you don't watch out!

WPF Basics: How To Play Sounds and Music in Windows Presentation Foundation

Ged Mead — Tue, 10 Jun 2008 08:46:00 GMT

Introduction

You'll know by now that I'm quite a fan of WPF, but I have to say that my first excursion into using sound in a WPF application was a bit of a disappointment. Rather frustrating too.

Maybe I expected too much, but I had this idea that the audio features would have been ramped up by the same kind of scale as the visual features have. Sadly that's not quite the case and, although things have moved on a tad beyond having to use the sound APIs directly in code, I still had to fiddle around more than I would have liked.

But as I say, maybe I'm just becoming spoiled by the wealth of other WPF features.

Anyway, as I had to create a test project to work out how I could get the sounds to play as and when I needed them, I thought I'd blog some of the results.

To keep this to a reasonable length, it will be more of a "here's how" approach than a "why it works that way" one. Also I will be creating everything in code, not markup. There are several more approaches and advanced techniques available via XAML that I won't be covering here.

PART 1 : The SoundPlayer

1. Hard Coded File Path

Starting with possibly the least realistic scenario, you can use the SoundPlayer to play a .wav file by pointing directly to a file via a hard coded path.

Code Copy

Imports System.Media

    Private Sub Button1_Click(ByVal sender As Object, ByVal e As System.Windows.RoutedEventArgs) Handles Button1.Click
        Dim player As New SoundPlayer("C:\Temp\4WAY.WAV")
        player.Play()
    End Sub

Note the Imports statement at the top.

This wave file will play asynchronously (I do wish someone would come up with an easier to type word than that! - it's nearly as bad as 'concatenation' ) But I digress....

If it's a particularly large wav file, you can help things out by inserting a Load statement after the initialization and before the Play fires. This will tee the player up to play without any kind of pause while it cranks up the file. This is something well worth bearing in mind as we users have become more and more impatient of delays.

2. Use a Content File

One particularly useful approach which gets around all the potential problems of hard coding file paths is to add the file to your Solution Explorer items. You can do this with the standard "Add Existing Item" selection from the IDE menu, adding the wav file directly to the list of files for the Project.

This now brings me to Frustration #1. First, here's valid code to play the sound using a SoundPlayer object:

Code Copy

    Private Sub Button6_Click(ByVal sender As System.Object, ByVal e As System.Windows.RoutedEventArgs) Handles Button6.Click

        Dim player As New SoundPlayer
        player = New SoundPlayer("SND0103.WAV")
        player.Play()

    End Sub

Now, before we move on, let's check the Solution Explorer:

As you can see the file name is correctly entered and that file is sitting in the Solution Explorer's list of files that (you would think) it knows about.

The key to fixing this problem is the 'Copy to Output Directory' Property. By default, this is set to 'Do Not Copy'.

You need to change this to 'Copy Always' and you'll be back on track.

3. Audio File as Resource (Frustration #2)

I wasn't going to include this option because it has generally caused me more trouble than it's worth (especially bearing in mind that there are several relatively trouble-free alternatives). However, you can add a wav file as a Project Resource as normal and then play that Resource via a Stream.

The syntax is:

Code Copy

  Private Sub btnResource_Click(ByVal sender As System.Object, ByVal e As System.Windows.RoutedEventArgs) Handles btnResource.Click
        Dim player As New SoundPlayer(My.Resources.canon)
        player.Play()

  End Sub

Even with small, well tested files I often found that using this approach I would get a lot of unacceptable sound distortion (actually additional unrelated sounds to that expected). I have tried it on several PCs, each with different sound card configurations and the problems occur on them all.

5. Other SoundPlayer Features

In addition to the standard Play method, the SoundPlayer has a PlaySync method - in case you should rather unusually want the system to be locked until the sound has finished playing.

And finally if you want a sound to be repeatedly played, you can use the PlayLooping method to drive people mad; sanity can be restored by inserting the Stop method!

PART 2: MediaPlayer and Media Element

As you've already seen, the SoundPlayer has some limitations. It only understands wav format files and you can generally only play one wav file at a time (unless you start to get quite fancy with multithreading). In many cases, the MediaPlayer or MediaElement will be a better option, but there is a good reason why I included the discussion of the SoundPlayer above. In some situations on particular systems you will have problems getting the two Media components to work properly. So it's always useful to know how to use the lighter weight SoundPlayer if you run into these problems in the future.

6. But I Want to Play MP3 Files!

- or WMA or MID, etc. for that matter. And this is a job for either the MediaPlayer or MediaElement. Keeping to my approach of doing all the work in code, I'm therefore going to home in on the MediaPlayer. (If you have a need to create a media object in XAML and have it play, pause, stop, trigger, etc, only in XAML then the MediaElement will be your tool of choice.)

Before abandoning the MediaElement approach altogether, I should point out that you can create the MediaElement in XAML and then access it's properties and methods in code. However, there is no advantage that I know of and in fact, the syntax is slightly more verbose and it also caused Frustration #4 - the fact that the audio file will only play once and then needs to be 'reset' by calling its Stop method; the Stop method apparently has the effect of returning the playhead to the beginning of the file.

So let's look at the MediaPlayer in WPF. It has an Open method which loads the file in the form of a URI. This was Frustration #5 for me, as it took me a while to get past the problem of the "Value of Type 'String' cannot be converted to 'System.URI.'" error. It took a lot more than a quick search to finally discover that I needed simply to add the URIKind argument to the Open method; so the considerable amount of time I spent trying to do casts was wasted. But maybe that's something I should have known.

It also has Play, Pause and Stop methods, plus the more sophisticated Balance and Volume properties.

There is another small Gotcha involved in using this control. Take a look at the following code snippet:

Code Copy

Dim mplayer As New MediaPlayer
mplayer.Open(New Uri("Godfather.mp3", UriKind.Relative))
mplayer.Play()

It's hard to see anything wrong with that code snippet, but if you do try it you'll find that the audio will play for a short period of time and then - for no apparent reason - stop. This is Frustration #6.

As I understand it, what happens here is that the new MediaPlayer object is created, passed a URI for its source and then instructed to play. Play begins but at that point seemingly the MediaPlayer closes itself, saying "I've set the audio away, so my work here is done". The end result is that at some unpredictable point in time the closed MediaPlayer is released from memory and will be disposed. And of course as soon as it no longer exists there is no means for the sound to continue to be played. So it stops in mid note!

Anyway, having dragged you laboriously through that explanation, you'll probably already have realised that the fix is simple. All you need do is instantiate the MediaPlayer outside the scope of the click event so that the MediaPlayer will continue to exist throughout the lifetime of that Window or Page. In other words, like this:

Code Copy

Class Window1
    Dim mplayer As MediaPlayer

  Private Sub Button1_Click(ByVal sender As Object, ByVal e As System.Windows.RoutedEventArgs) Handles Button1.Click

        mplayer = New MediaPlayer
        mplayer.Open(New Uri("Godfather.mp3", UriKind.Relative))
        mplayer.Play()

    End Sub

End Class

As with the SoundPlayer sample, the mp3 file has been added to the project files in Solution Explorer, its Build property set to Content and its Copy To Output Director set to Copy Always.

If the file is extra large and you get a pause before it actually begins to play then you can of course move the mediaplayer instantiation and Open code to, for instance, the Window Loaded event or some other place where the delay won't be so obvious. It will then be teed up ready to go as soon as the Play method is invoked.

7. Summary

There isn't much else to add. I think you now have the tools you need to play sound and music files in WPF. By the way, that does also mean both sounds and music at the same time, because you can have multiple instances of MediaPlayers running concurrently (or MediaPlayer(s) and a SoundPlayer running together). Therefore you can have almost any combination of sound files running, subject to the limitations of your system, that is.

I hope you will find this information useful in your future projects if you need to include sound and want to avoid the frustration of the learning curve.

Searching Through Folders to Find File(s)

Ged Mead — Wed, 04 Jun 2008 16:10:00 GMT

I was looking for a task to use as the background task of my recent article on the BackgroundWorker component and decided that I'd use a recursive search through folders. Ironically, I ended up spending about twice as much time on getting the recursive search procedures running correctly than I spent on the main BackgroundWorker code.

As I ended up with three varieties of recursive searches - and found some things that should have worked, but didn't seem to - I thought I'd blog it.

To find a particular file type in folders and sub-folders I used this code:

Code Copy

Sub FileFinder(ByVal dir As String)

        Try

            ' Display all files in a directory that match file type
            For Each fname As String In IO.Directory.GetFiles(dir)
                If fname.EndsWith("txt") Then
                    '  pass back progress message
                    Console.WriteLine(fname)
                End If
            Next

            ' A recursive call for all the subdirectories in this directory.
            For Each subdir As String In IO.Directory.GetDirectories(dir)
                FileFinder(subdir)
            Next
        
        Catch ex As Exception
            MessageBox.Show(ex.Message.ToString)

        End Try
    End Sub

You'll probably have spotted that I used the "EndsWith" function there to test for the tile type I'm interested in. Originally I tried using the SearchPattern parameter of the GetFiles method, but for whatever reason it didn't identify the files for me.

Another little glitch to keep in mind is that there may be some files to which users don't have authorised access. If for example you call the above code and pass in "C:\" as the argument you will probably get one or more "Access Denied" messages via the Exception Handler. Of course, because the exception is being handled, the user can click on the messagebox's OK button and the procedure will continue to run.

Obviously, to avoid the message appearing at all you can just comment out the MessageBox.

If you want to home in on that particular issue and allow access but still want to know if other kinds of problems occur then you can fine tune your structured exception handlers (as of course you should) and include a handler specifically aimed at the access exception:

Code Copy

Catch ioex As System.UnauthorizedAccessException

   ' Access Denied Problem will be handled here

Catch ex As Exception

    ' Other Exceptions will be flagged up to users

    MessageBox.Show(ex.Message.ToString)

Hard coding the file type limits reusability, so a better version would be:

Code Copy

  Sub FileTypeFinder(ByVal dir As String, ByVal FileExt As String)

        Try
            ' Display all files in a directory that match file type
            For Each fname As String In IO.Directory.GetFiles(dir)
                If fname.EndsWith(FileExt) Then
                    '  pass back progress message
                    Console.WriteLine(fname)
                End If
            Next

            ' A recursive call for all the subdirectories in this directory.
            For Each subdir As String In IO.Directory.GetDirectories(dir)
                FileTypeFinder(subdir, FileExt)
            Next

        Catch ioex As System.UnauthorizedAccessException

        Catch ex As Exception
            MessageBox.Show(ex.Message.ToString)

        End Try

    End Sub

The client now passes in the file type as well as the parent folder.

The final version I used was one which recursively searched through folders and subfolder, found files that matched a particular file extension and then searched inside matching files for a particular string. This of course could be a particularly long task in some cases and so a good candidate for the BackgroundWorker.

Code Copy

    Private Sub FileContentFinder(ByVal dir As String, ByVal FileExt As String, _
                                 ByVal TargetText As String)
        Dim rdr As IO.StreamReader

        Try

            ' Display all files in a directory that match file type
            For Each fname As String In IO.Directory.GetFiles(dir)
                If fname.EndsWith(FileExt) Then
                    rdr = New IO.StreamReader(fname)
                    Dim strFileContents As String = rdr.ReadToEnd
                    rdr.Close()
                    rdr = Nothing

                    ' If this file contains the target string, pass back progress message
                    If strFileContents.Contains(TargetText) Then
                        Console.WriteLine(fname)
                    End If
                End If
            Next

            ' A recursive call for all the subdirectories in this directory.
            For Each subdir As String In IO.Directory.GetDirectories(dir)
                FileContentFinder(subdir, FileExt, TargetText)
            Next

        Catch ex As Exception
            MsgBox(ex.Message.ToString)

        End Try

    End Sub

There are many other twists you could use on the above approaches, such as testing against file attributes for dates, for example, or copying files that meet certain criteria.

WPF Basics: Using Animation to Fade Colors In and Out

Ged Mead — Wed, 07 May 2008 21:03:00 GMT

One of the great things about WPF is its ability to let you use animation to enhance your user interface. (Or wreck it if you go too far!) In my opinion, subtle animations can go a long way towards improving the user experience.

One particular way is to fade colors in and out so that text seems to appear and disappear in a way that gives the impression of movement, but without any jarring visual effects.

Doing this in the XAML markup is well documented and you will find many examples around the place. However, I recently had a situation where I wanted to create this animation in the VB code behind. Now, I knew that anything that could be done in XAML can be done in VB, but when it came down to the task it actually caused me more problems than I'd expected. And when I started to search for answers, it took a while.

It turned out that the reason for my difficulty was a fundamental misunderstanding on my part. I was thinking "color" as being the element to change or animate; in reality it doesn't work quite like that. But after a good deal of trial and error, I eventually hit on the answer.

In this case I wanted to fade the text on a button from its original black to white. But because I would use this effect in a number of situations, including some where there was no user driven event to fire it, I decided that putting the animation instructions in the code behind was the way to go.

I'll start with the XAML though, as I think that in most cases this will be your preferred route. I'll cover the VB approach at the end.

here's the XAML:

Code Copy

<Button Margin="30,67,0,111" Name="Button1" Foreground="Black" HorizontalAlignment="Left">Animated Button</Button>
  <Button HorizontalAlignment="Right" Margin="0,77,96,111" Name="Button2" Click="Button2_Click" Content="Animated Button" >
    <Button.Triggers>
      <EventTrigger RoutedEvent="Button.Click">
        <BeginStoryboard>
          <Storyboard TargetProperty="Foreground.Color">
            <ColorAnimation To="White" Duration="0:0:2" />
         </Storyboard>
      </BeginStoryboard>
    </EventTrigger>
  </Button.Triggers>
</Button>

Most of it is pretty straightforward:

1. Having first created the button and set its main visual properties, we create a Triggers block for the Button.

2. Next we identify the trigger to be used to fire this animation. In this case it is the Button's Click event.

3. The Storyboard is then created and we identify the Target Property which is the Foreground Color of the button.

4. Finally, the animation details which comprise the starting color, the ending color and the duration in seconds.

The remainder of that code snippet are closing tags.

Now it's the fact that the TargetProperty is identified as the Foreground.Color that threw me off the track when I came to create a VB version of this task. I was trying to find a way of assigning the animation directly to the Foreground Color of the button (or the Button.Content Color or various other permutations - none of which worked).

The reason is that you have to set the animation on a Brush, and not directly to the Foreground property. You then assign this brush as the one to be used for the Foreground. And finally, when you run the animation to change the color of the brush, the animation is then seen to be applied to the Foreground. I hope that makes sense!

Here's the VB code that does this:

Code Copy

' Create color animation sequence.
Dim blackToWhite As ColorAnimation = New ColorAnimation(Colors.White, New Duration(New TimeSpan(0, 0, 2)))

'Create a new brush and apply the color animation to the brush
Dim scb As SolidColorBrush = New SolidColorBrush(Colors.Black)

scb.BeginAnimation(SolidColorBrush.ColorProperty, blackToWhite)

'Assign the brush to Button's Foreground
Button1.Foreground = scb

Like all these little glitches and gotchas, you wonder how it seemed so difficult once you've seen the answer. But as we all know, it's really easy to set yourself off on the wrong mindset and find yourself needlessly chasing your tail trying to get the exact syntax for what you're trying to achieve. Hopefully if you need to run this kind of animation in code, you'll now be saved a bit of potential frustration.

VB 2005: How To Print With Word Wrapped Lines

Ged Mead — Tue, 08 Apr 2008 17:06:00 GMT

Introduction
Printing can often be a bit of a tricky task in .NET. Some things are more easily resolved than others though.

I saw a post recently that raised a problem that seems to occur fairly regularly: You want to print a large chunk of text to the printer, but VB seems to want to print everything all on one long line - even when this means that a lot of the text will be truncated or "printed" invisibly into thin air!

Fortunately, this is one of the cases where the solution is relatively easy. Essentially, what you do is set a rectangle whose width represents the width of your printed page (or any lesser width you prefer). You then pass this rectangle to the DrawString method and it will obediently print within those boundaries.

Solution
Here's the basic solution:

Code Copy

  Imports System.Drawing.Printing

Public Class frmPrint

    ' The document you will use to print on
    Dim DocPrint As PrintDocument

   ' Set font for printing
        Dim fnt As Font = New Font("Verdana", 12, FontStyle.Regular)

'  The printing is fired with a button click event
    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        '  Print the textbox content

        DocPrint = New PrintDocument
        ' A handler for it
        AddHandler DocPrint.PrintPage, AddressOf PrintTheTextBox1

        ' Print the document
        DocPrint.Print()
    End Sub

  '  The procedure that does the printing
  Private Sub PrintTheTextBox1(ByVal sender As Object, ByVal e As PrintPageEventArgs)

        'Set a rectangle to bound the  printing
        Dim PrintRect As New RectangleF
        PrintRect.Width = 800
        PrintRect.Height = 1000

        ' Print the text from the TextBox:
        e.Graphics.DrawString(TextBox1.Text, fnt, Brushes.Black, PrintRect)

    End Sub

Yes, But.....
That's OK as far as it goes, but it does suffer from one flaw. When you check your printed page you'll find that the text is stuffed right up at the top left of the paper and each line extends fully across to the very last few millimetres at the right hand side. Now, it may be that paper saving is high on your agenda, in which case you'll be happy. But generally you will probably want a layout that's a bit more generous with its whitespace.

The trouble is that there isn't an overload that allows you to pass in the Rectangle and the start position for the printing. Is that going to stump us? Nah, of course not!

If we go back to the Rectangle itself, there is a constructor overload that allows you to pass in the x and y values as well as the width and height. The x and y values will of course be used as the left and top points respectively of the rectangle as it is positioned on the printed page. So this variation will get the start position, the text line width and text block height all sorted:

Code Copy

Private Sub PrintTheTextBox2(ByVal sender As Object, ByVal e As PrintPageEventArgs)

        'Set a rectangle to bound the  printing
        Dim PrintRect As New RectangleF(30, 100, 750, 1000)
       '  Assign its Left, Top, Width and Height values

        ' Print the text from the TextBox:
        e.Graphics.DrawString(TextBox1.Text, fnt, Brushes.Black, PrintRect)

    End Sub

While I was working on that, I remembered that the Rectangle has a useful little method named Offset (something you would normally use when drawing actual rectangles in a graphics based task). However, by using this method and adjusting the values that are passed so that the top left of the rectangle is shunted down and to the right, we can get nearer to the layout we desire. If you chose to use this alternative route, it would look like this:

Code Copy

Dim PrintRect As New RectangleF
        PrintRect.Width = 800
        PrintRect.Height = 1000
        PrintRect.Offset(25, 60)

Show Me The Width
It probably won't have escaped your notice that I very conveniently just happened to know what width and height I needed for the text to span across the page. Many times you will have this information to hand, but if you don't, what do you do then? Answer: You calculate it by querying the PrintDocument's PageSettings, find the width, height and margins and use those. Here's the code:

Code Copy

   Private Sub PrintTheTextBox3(ByVal sender As Object, ByVal e As PrintPageEventArgs)

        'Set a rectangle to bound the  printing
        Dim PrintRect As New RectangleF

        With DocPrint.DefaultPageSettings
            PrintRect.Width = .PaperSize.Width - (.Margins.Left + .Margins.Right)

            PrintRect.Height = .PaperSize.Height

            PrintRect.Offset(.Margins.Left, .Margins.Top)
        End With


        ' Print the text from the TextBox:
        e.Graphics.DrawString(TextBox1.Text, fnt, Brushes.Black, PrintRect)

    End Sub

Summary

Although there are many more tweaks we could add to this approach, I think that the above will cover many common situations. If text trimming at the end of lines is something you need to refine to the nth degree then you should check out the StringFormat class in general and the StringTrimming enumeration in particular. There are several options available there.

Don't forget of course that you may not need to hand code your printing processes at all. There is a free Power Pack available which will print the contents of a form with minimum effort on your part. This will often be all that you need, but if not then at least you now know how to package up a bundle of text and send it to the printer to be laid out in a way that suits your requirements.

Pro WPF with VB 2008 by Matthew MacDonald

Ged Mead — Sun, 06 Apr 2008 11:02:00 GMT

Friday was something of a Red Letter Day in the Mead household, because that was the day that the book I've been looking forward to getting for months finally arrived on my doorstep. At last - a WPF book aimed at those of us who prefer to use Visual Basic for the code behind. The book is Matthew MacDonald's "Pro WPF with VB 2008", published by Apress.

In the couple of days since it arrived I obviously haven't been able to get too deeply into reading it - although my wife might offer a different opinion on how many hours I've spent with my head in this book since Friday! However, it's immediately clear that this is another well-written and comprehensive piece of work from a widely respected author.

Unsurprisingly, large chunks of content have been ported directly from his earlier WPF book, which was based on .NET 3.0 and has C# as the code behind. This makes complete sense as it is only the code behind aspects that need the different approach. We VB-ers are just as able to understand the general WPF and XAML explanations as our allegedly "sharper" developer brethren.

Because this is based on WPF 3.5 though, there are some additional items, such as binding to a LINQ expression in Chapter 16. There is also a completely new additional Chapter 26, which deals with the topics of Multithreading and Add-Ins.

I don't think Apress have the full chapter listing on their site yet (or at least I couldn't see it if they did). However, rest assured that the whole gamut of WPF topics is covered in this book, from Layout to Dependency Properties, Routed Events to Navigation - in fact everything from Animation to Z-Index.

The author has a very useful list of links that you can simply click on to save you (mis)typing them yourself from the book. These links and the downloadable code samples are available from here.

In my opinion, you should buy this book for two reasons.

First, it is an excellent, wide ranging, clear description of what you will need to know in order to get fully to grips with this exciting (but not always intuitive) technology.

Second, there have been at least five WPF books published in the past year that have C# as the code behind. Publishers are in the business of selling books and they couldn't care less about whether C# or VB are "better". So I guess it's obvious that their stats show that they will sell more C# books. If you want to keep VB as a viable language, fully supported by authors and publishers, then the only way to ensure this is to make it worth their while to publish VB based books.

So for either or both these reasons, I rate this book as one of the most worthwhile investments you can make if you are a VB developer (or student) and you want to fully embrace all the tempting offerings available in Windows Presentation Foundation.

Developer Day Scotland - 10th May 2008

Ged Mead — Thu, 03 Apr 2008 08:14:00 GMT

The day of the first ever Developer Day Scotland is getting close! Registration is still open and I hear that there are still a few places left.

So if you are anywhere in reach of Glasgow on Saturday 10th May 2008 and want to take advantage of this FREE event for developers, you can Register from this page.

Wondering what's in it that might interest you? Check out the agenda here.

Colin and the guys have put in a huge amount of effort to get this off the ground, so I'm sure it will be a great day and well worthwhile attending.

By the way, on a personal note, I'm hoping to use the event to assess if there is enough interest around to start a SouthWest Scotland (or even a SW Scotland and Cumbria) Section of Scottish Developers. So if you live in this general catchment area and think you could be interested in joining such a group, please talk to me on the day. And if you can't make the day and are still interested, contact me via this blog or email to xtab at vb(nospace)city dot com.

Murach's Visual Basic 2008 - Book Review

Ged Mead — Sun, 09 Mar 2008 15:07:00 GMT

The latest .NET book from the Murach publishing house is "Murach's Visual Basic 2008". This book is essentially an update of their earlier book for VB 2005 which now includes additional coverage of new features such as Anonymous Types, Object Initializers and LINQ.

I've just been re-reading my original review of the 2005 book and much of what I said then applies equally to this latest version. Here's what I said then:

We all find that some particular authoring styles work better than others for us individually. Some of us like a mass of detail and repetition; some like a few terse lines of explanation. Some of us like to be jollied along with the occasional funny; some like to stay serious. Some like the pages to be jam-packed with screenshots and diagrams; others think this is a waste of teaching space.

It's an individual thing.

Murach have developed their own particular individual style. They use a "facing page" technique. Open the book up at any section and on the left hand page you will find a discussion or explanation of a topic. On the facing page you will see more specific information about this topic, possibly with a diagram or screenshots, or very often demonstration code samples.

The benefit of this approach is that the author has two bites of the teaching cherry. She (in this case, author Anne Boehm) can introduce a topic on the left hand page, cover the essentials and be ready to move on. The value of the right hand facing page though is that it can be used to show additional detail, display sample code and example results and also (this I think being very important) can summarise the key points covered on the first page. The reinforcement of learning points in this way can be a very valuable tool.

Essentially, the reader can decide if he or she has understood enough from the left side page to be ready to move on, or if not then they can opt to read the right hand page for more info, samples or reinforcement and confirmation of their understanding.

Personally I quite like the approach. I tend to dive into books almost at random sometimes, but often just needing to refresh my memory on a particular point. If I'm using a Murach book and need further detail, I can dig into the additional facing page info as much as needed for any one topic, or even specific part of a topic.

If there is a down side to the Murach approach it's probably that because of the facing pages approach they have to limit the number of VB.NET topics they can actually cover in the 800+ pages limit . That said, what they do cover is fairly comprehensive and contains plenty of material to keep a VB.NET beginner engrossed for many a long night. And, most importantly, those topics are covered thoroughly and clearly in plain English.

A full list of the book Contents can be seen here and as you will see, you can drill further into each chapter to exactly what is covered.

If you want to know if the Murach style will suit you, then you can take a look at two Sample Chapters here.

In summary, this is another clearly written, well laid out offering from the Murach stable. This book is particularly suitable for newcomers to VB.NET, whether total developer beginners or those moving to .NET from VB Classic.

Applications = Code + Markup : VB.NET Code Samples

Ged Mead — Sun, 09 Mar 2008 11:43:00 GMT

I've been working in conjunction with Evan Lim and Young Joo to convert the source code examples from Charles Petzold into VB.NET. As at today there still doesn't seem to be a WPF book on the market that has VB.NET as the code-behind (although I know there are a couple on the way). Add to this the fact that many C# to VB converters at the moment still get it wrong with several areas of the new Framework, this is a real stumbling block for many VB developers who would otherwise be much more interested in digging into WPF.

The link to the final version of the conversion of Petzold samples is here. You can download individual chapter code or the whole shebang from the links in that blog item

I've just started working on a similar project to convert the C# code of another WPF book. I'll post more once I've got something to show. In the meantime I hope that the Matthew McDonald and Billy Hollis WPF/VB books will be on the shelves before long.

VB2005: How To Remove an Item from a ListBox

Ged Mead — Tue, 19 Feb 2008 17:26:00 GMT

This is something that seems to come up fairly often in the Forums. Someone wants to test for a particular value in a ListBox and if the list does (or doesn't) contain the value then that item is to be deleted.

One common way of doing this would be to use the Contains function to test if the target character or substring exists in the ListBox.

This isn't a particular difficult task, but the thing that usually catches most beginners out here is that you have to traverse the ListBox items in reverse order. Well, you do if you actually end up deleting any items, anyway. The reason being that if you start from the top and work down, then as soon as you delete an item the ListBox's indices get out of sync and an ArgumentOutOfRange Exception will be thrown and you will get a message along the lines of the one shown below:

In a recent post, a slight variation on this theme was that the check was to be made in one ListBox and if the required search string wasn't found in that first ListBox then not only was the item in the first ListBox to be deleted but also the corresponding item number in a second ListBox was also to be deleted.

Again this is straightforward and the following code will do the job :

Code Copy

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        For i As Integer = ListBox1.Items.Count - 1 To 0 Step -1
            If Not ListBox1.Items(i).Contains(TextBox1.Text) Then
                ListBox1.Items.RemoveAt(i)
                ListBox2.Items.RemoveAt(i)
            End If
        Next
    End Sub

As I say, it's not rocket science, but that traversing upwards trick is something worth knowing for these kind of situations.

WPF Basics: Video Demonstration - Creating A Simple ControlTemplate

Ged Mead — Sun, 03 Feb 2008 20:08:00 GMT

I've had a copy of the excellent Camtasia Studio from TechSmith on my system for a while now and I've been itching to find time to create a video demo or two.

Just as everyone warned me it would be, it's a lot harder and takes wa-ay longer than you think it will, but my first effort is finally finished.

As you can see from the blog heading, the video is a mini-tutorial on the subject of how to create a simple ControlTemplate in WPF. The example I've used is a round button, just to show the techniques rather than try and get too fancy with the design.

It's 99.9% XAML; just one tiny bit of VB used to demonstrate that the templated button is wired up to the standard button Click event.

The full-length video runs to just over 12 minutes and you can access it from HERE

or download a zipped copy HERE

In addition, I was greatly encouraged by Karl Shifflett's clear and comprehensive article (not forgetting his demo videos!) on CodeProject to try and create a Silverlight version too. In order to keep within the bandwidth limitations, I've had to break the original demo into two parts.

You can view the same video streamed as a Silverlight application from the links below:

WPF ControlTemplate Part 1 Video

WPF ControlTemplate Part 2 Video

If you want to view the Silverlight versions full screen, select the button shown in the image below for Full Screen and the Esc key to return to Default Size

First Chance Exception and XamlParseException

Ged Mead — Fri, 01 Feb 2008 11:44:00 GMT

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.