vbCity

test

Admin — Tue, 14 Apr 2009 21:41:00 GMT

test

Admin — Tue, 14 Apr 2009 21:34:00 GMT

test

Admin — Tue, 14 Apr 2009 21:15:00 GMT

test

Admin — Tue, 14 Apr 2009 21:08:00 GMT

test

Admin — Tue, 14 Apr 2009 21:03:00 GMT

test

Admin — Tue, 14 Apr 2009 20:22:00 GMT

test

Creating Video Demos With Camtasia Studio

Admin — Fri, 23 Jan 2009 17:28:00 GMT

I've been meaning to blog about the tools I use regularly and find useful and I've managed to get a couple written this month. I'm always a bit concerned that blogs like this might end up looking like some kind of infomercial. But I eventually came to the conclusion that I've always thought that personal recommendation was the best kind of recommendation, so if I like a tool I should tell the world. Whether the world sets any store by my opinion is a matter for the world to decide! J

I have been using Camtasia Studio on and off for a couple of years now. When I first got hold of a copy, I needed it to create some demo videos. What I really liked about it was that, with no previous experience of screen recording, I was able to make the recording successfully after only a couple of tries. OK, so when I look back at that effort now, maybe "successfully" is an extravagant claim, but it was good enough for what I wanted to do at the time.

Although there are still some (many!) features that I haven't yet got round to using, it has still been a really useful tool for me. When I first got it, I was more interested in grabbing the screen action and recording some audio narration. More recently, I needed to improve the narration side and so was looking for a way to record the voice independently and (often) edit parts of it without having to re-record the whole thing for the umpteenth time.

Camtasia Studio comes with a subset of handy little apps, one of which is their Audio Editor. This has been really useful, as it enabled me to make those voice recordings and edit them easily. I also found myself doing a lot of "Inserting Silence" to replace the intakes of breath and the occasional unwanted clunk when I'm waving my hands around and hit the boom mike.

The tutorials are excellent and there is a lively set of User forums. FAQs are available to help you with those tricky things that should go right but somehow don't.

The work area is as easy to use as you could reasonably hope for with an application that seems to have so many options. As you can see from the screenshot, the timeline allows for more than one audio track.

Version 6 of Camtasia comes with even more presets to help you create the best screen size, resolution and (often important for web distribution or viewing) file size.

I'm currently working on creating some courses, all of which contain video demos. As I get more used to using it, I am of course finding that I can get from starting idea to finished production much quicker. When I've finished my current project, as a long term plan, I hope to be able to create a set of short videos to be made available for free here on VBCity.

All in all, I'm really pleased with it and many a time I've silently thanked the friend who first put me on to it. You can download a free 30 Day trial version from the TechSmith site here.

The Best WPF Developer Books

Admin — Sun, 18 Jan 2009 20:10:00 GMT

I now have several WPF books. I've written reviews on some of them and often mentioned them in answers to Forum questions from members who want to start out in WPF.

When I wrote those articles and answers, my opinion was mostly based on my experience as a general reader who was interested in seeing what WPF had to offer and dabbling with it at a fairly elementary level. For the past three months though, I've been involved with WPF on a daily basis in a training capacity. During this time, it's become clear that I turn to some of the books much more regularly than others - and to some of them only when fairly desperate).

With the very clear understanding up front that this is my personal experience, opinion and preference - which may be completely different from anyone else's - here is my view on the various books.

The book I first turn to is :
Pro WPF with VB 2008: Windows Presentation Foundation with .NET 3.5
by Matthew MacDonald.

Comprehensive, detailed, clearly written, understandable code snippets, and downloadable code samples that work.

It's almost impossible to fault this book.

And of course, as the title says, the code behind samples are all in VB.NET - the only book I know of so far that is aimed specifically at VB developers.

However, if you are a C# developer then that won't impress you much. For you, Apress and Matthew MacDonald have produced the equivalent C# title - Pro WPF with VB 2008: Windows Presentation Foundation with .NET 3.0. The key differences obviously being the absence of "VB.NET" in the title and the slightly earlier Framework.

I do have this version too and find it very useful when I want to try and understand the C# approach to a concept that I understand in VB.

The next book I reach out for is usually
Windows Presentation Foundation Unleashed
by Adam Nathan.

The key value of this book is that it is packed with little hints, tips, Gotchas and information that will help you fight your way through the minefield that you encounter when first starting with WPF.

One negative for me is that the code samples are in C#. There are however many useful XAML samples.

The book is in full color. This makes it slightly more attractive, but isn't a key issue for me.

Compared to most other WPF books, it appears to be relatively slim. In spite of this, I have still found it to be a gold mine of really useful WPF nuggets.

Third in line is:
Programming WPF
by Chris Sells and Ian Griffiths.

Another C# book, but again contains a lot of XAML. Ian Griffiths was one of the first writer/speaker/presenter/trainers on WPF in general and XAML in particular, so there are some useful insights to be had here.

On the negative side, my impression is that the authors prefer to use code behind sometimes where I would have liked to see the XAML alternative.

Make sure you get the Second Edition if you decide to go for this book. The First Edition is inevitably way out of date now.

Surprisingly (to me anyway, considering I spent a lot of time converting the code in the next book from C# to VB) the Petzold book only comes fourth in my list of most used books. This is:
Applications = Code + Markup: A Guide to the Microsoft Windows Presentation Foundation
by Charles Petzold.

If you want intricate details and almost philosophical insight into the structure of WPF, then this would be the book for you. As with all Petzold books, it painstakingly works its way through the minutiae of the subject.

If I have a criticism, it would be that sometimes the sackcloth and ashes approach to developing (such as manually creating everything yourself, even if it is available for free) doesn't always work for me. I understand the purity of the approach, but this means that it can sometimes be difficult to just dip into this book for a quick answer to a particular question.

However, if you really - really - want to get at the nuts and bolts of WPF, then you will probably not find one that has more detail.

The fifth book in my WPF stable (for now, anyway!) is:
Professional WPF Programming: .NET Development with the Windows Presentation Foundation
by Chris Andrade and others.

When there were very few other books available, this one had some benefits. The authors had each looked at specific areas and came up with some guidance. Some parts were clearly better than others, but overall it was an easier read than MSDN at the time, but basically rather shallow coverage.

It rarely gets opened these days.

I have the greatest respect for anyone who takes the time, trouble and effort to write or co-write a book. Knowing how long it takes me to write a short article or a training package, I wouldn't dream of criticising someone who will have spent many long, hard months writing (and no doubt re-writing) a book. So, as I said at the start, the opinions in this blog item only reflect my personal experience of using this collection of books; other readers with other backgrounds and author style preferences may well have different opinions.

As WPF picks up speed and interest grows, I'm sure there will be many other WPF books published in the coming months. There are already several that were published at the end of 2008 that I haven't read. No doubt the temptation to pick up another title or two will become irresistible as 2009 progresses and, if so, I will post up my thoughts on those too in the hope that it might help you decide the best way of spending your hard-earned cash.

WPF Commands and PerformClick

Admin — Sun, 18 Jan 2009 18:04:00 GMT

Some weeks ago I wrote a blog item about how to get the functionality of PerformClick in WPF.

I remember thinking at the time that it was a fairly clunky workaround and wondered why PerformClick hadn't been included in WPF. Of course there may be lots of reasons, beginning with 'No-one thought of it' and ending with 'It was just too difficult'.

But while looking at an apparently unrelated problem this week, it occurred to me that maybe there is a more elegant solution staring me in the face - WPF's Commands.

In many cases where PerformClick is required, the situation is that whatever action is wired up to the Button's Click event is often also of interest to other controls - perhaps a menu item, a keyboard shortcut or a user instigated selection of some kind or other elsewhere.

WPF Commands, if this is a new area for you, is a variation on the theme of Events. Whereas events are generally locked in to a specific action, a Command on the other hand is more along the lines of a loosely-coupled task that can be subscribed to from several places.

Of course,you may be sat there thinking that it doesn't take a coding genius to create code for events that can be re-used and accessed from several different points. The point is though that Commands are specifically designed for this purpose and they have a feature that I think makes them almost unique. (Can you be 'almost' unique, the literary critic part of my brain asks? Never mind, you know what I mean!)

Commands have the ability to turn themselves off in situations where it wouldn't be appropriate for them to be available - and back on again when it is. A common example is the Paste Command, where it doesn't make sense to have it available unless there is some data in the Clipboard.

Similarly, you might build in a test where the Exit command isn't allowed to function unless the user has taken some action, such as saving data. There are lots of similar examples.

WPF comes with a bundle of pre-built Commands for common tasks, including Copy, Cut, Paste, Find, Save, Close, Play, Zoom, Align and many more. Naturally, the designers of WPF don't know the exact actions you will want to link to each of the commands in every circumstance, so there is still some work for you to do. Commands are clever - but they're not magic!

Apart from the built in Commands, and on the basis that there are never enough of these kind of things, you can create Commands of your own relatively easily. You can set the bindings and the rules that decide when it may be able to execute and when not (as per the Paste example earlier).

All of which brings me back to my original thought. If you can create a Command that both a Button and (in the case of the Forum question that got me thinking about this) a Menu Item can bind to, then that really removes the need to worry about PerformClick. Command would be a neater and more sophisticated way of achieving the same effect.

If you want more info on Commands, here is a useful link to an MSDN Introduction to Commands article.

New Blog

Admin — Thu, 18 Dec 2008 18:19:00 GMT

Just to let anyone who might be interested know that my Blog has now moved to http://cs.vbcity.com/blogs/skullcrusher/default.aspx

WPF Text Tricks - MultiLine Text and Multiple Spaces

Admin — Sat, 13 Dec 2008 00:51:00 GMT

When it comes to text handling in WPF, you have a massive range of tools available, some of which can offer you a level of granularity that was previously unachievable. I plan to write about some of these text tools, such as Spans, Runs and Glyphs in future blogs, but for today I want to look at something a little less deep.

Recently I needed to insert a carriage return in a block of text. The text was being created in the XAML markup, and I didn't particularly want to resort to code-behind for what is essentially a UI feature. So I had to do a bit of digging to find how I could create, for instance, this result:-

where, if I don't override it, the two words would be placed one after the other on one line because there is more than enough width for them both.

As you might expect, there are several ways of achieving this, but I think the easiest one is to use a LineBreak element. This snippet shows the key part of the code that creates and formats the Button's Content, which in this example is of course text only.

    <Button Margin="12,45" >
      <TextBlock> Click <LineBreak/> Me!</TextBlock>
    </Button>

You might think it a bit strange when you see that XML type item stuck into the middle of a block of text, but this is perfectly valid syntax. Because the Content isn't a single block of text, it's necessary to use the TextBlock to house the text and the LineBreak instruction.

Actually, what I really wanted to do wasn't quite as plain as the above screenshot. It was more along these lines:-

The markup for this is still not particularly complex. It just requires more properties to be set specifically:

    <Button  Margin="12,45" Background="LightSkyBlue">

      <Button.Content>

        <TextBlock TextAlignment="Center" FontSize="16" FontFamily="Calibra"

                   FontWeight="Bold" Foreground="Navy" FontStyle="Italic" >

          Click <LineBreak/> Me!</TextBlock>

      </Button.Content>

    </Button>

I did mention that there are several ways and these include using a StackPanel containing multiple TextBlocks or setting the Padding property on a single TextBlock. An alternative you might consider is to preserve the whitespace. This effectively means that however you enter the text layout in your XAML will be faithfully reproduced in the WPF display.

The following markup:

    <Button  Margin="12,40">

      <TextBlock FontSize="14" VerticalAlignment="Center"

HorizontalAlignment="Center" xml:space="preserve">Click

Me!</TextBlock>

    </Button>

will achieve a similar result:

However, I really don't think the way the Markup sits in the XAML markup window is particularly neat. If you're interested in experimenting, try moving the word "Me!" so that it is more neatly aligned. Or Start the word "Click" on a new line of its own, maybe aligned with the markup above it.

The results are unlikely to be what you wanted to achieve and this is because the preservation is absolute. A XAML twist on WYSIWYG!

However, I included it here because the space preserve approach will be very useful to you in those cases where you want more than a single space between words or characters. Simply type out the text with the exact spacing that you require, set the XML Space attribute to Preserve and your requirements will be honored.

    <Button  Margin="12,40">

      <TextBlock FontSize="14" VerticalAlignment="Center"

          HorizontalAlignment="Center"

          xml:space="preserve">Name:    Ged</TextBlock>

    </Button>

So there are a couple of tips for dealing with text in WPF. There's more to come!

Formatting XAML Code Samples for a Blog

Admin — Thu, 11 Dec 2008 17:18:00 GMT

For several years, whenever I've needed to include code snippets in my blogs and articles, I've used a neat little application that VBCity member HotDog wrote. This has stood me in good stead until the day that XAML arrived on the scene. Unfortunately, XAML kinda confuses HotDog's AutoFormatter tool and I end up with missing angle brackets.

A bit of searching led me to a tool called CopySourceAsHTML. Although I had seen this used with Visual Studio 2005, there was a minor problem using it with 2008 for a while, but this was easily fixed with a minor tweak.

Now though there is an official Visual Studio 2008 version. The extra good news about this is that it will also copy XAML to HTML.

One thing to watch out for if you have used the tool before and usually right click on a code snippet to copy is as HTML:

you will expect to see the Copy As HTML option in the menu.

However, this doesn't appear in the context menu if you right click on the markup in the XAML Markup Pane. But it is available and all you have to do is go to the IDE main menu, select Edit and the Copy As HTML menu item will be available for you there.

This great little utility is written (and updated) by Colin Coller of J T Leigh and Associates. You can download it from here.

WPF Gotchas: What's the WPF Equivalent of the Text Property?

Admin — Thu, 11 Dec 2008 17:13:00 GMT

One of the things that often pulls me up in mid flow when I'm putting WPF UIs together in a Window is that some of the core properties seem to have disappeared. Now, some of these are so fundamental that I know they have to be there, but obviously hiding under a different name.

Just recently, this happened to me twice in a row and I ended up scrolling through the Properties in the Object Browser, getting dizzy with the whizzing list of choices until I finally found them. All I was looking for was a very simple thing in both cases. I just wanted to apply some text to a control.

The first one was the good old CheckBox. In Windows Forms this has a Text property, of course, and it's whatever textual information you want to place at the side of the little square check area. The WPF CheckBox will allow you to do a zillion clever things to change its look - add Borders, TextBlocks, Images, Panels, whatever you like - and at times I'm really happy about that. But as it happened this time I just wanted to plonk a couple of words of description at the side.

You'll have gathered that there isn't a Text property for the WPF CheckBox and after a bit of a search, I did find its replacement - the Content property. If you assign plain text to this property, WPF will honor your choice. So this:

   17 <CheckBox x:Name="CheckBox1" Content="Click Here" />

will do the job nicely.

Subsequently I discovered that the Content property is in fact the default property of a CheckBox, so this too will work:

   17  <CheckBox x:Name="CheckBox1">"Click Here"</CheckBox> 

Of course if you do want something more exotic, then you still use the Content property - you just add whatever multiple layers of content you desire.

The other control for which I had to search for the same kind of thing was the Expander. Again I only wanted a property that would just tack some plain text to the side of the Expander's little arrow.

This time the answer is to use the Expander's Header property.

<Expander Header="See More Choices"></Expander>

You can assign plain text to this property, but again you have the option to, well, expand the Expander's Header to make it a little more graphically interesting.

using this XAML:

      <Expander.Header>
          <Border BorderBrush="Navy" BorderThickness="2" CornerRadius="6">
            <TextBlock Margin="10,2,10,2" 
            Foreground="Navy">What do you want to do?</TextBlock>
          </Border>
        </Expander.Header>

Although Content is the default property, don't fall into the trap of trying to use it as:

   20  <Expander> Click to view choices </Expander>

because that inserts the text as the first (and in this case, only) item in the area that you get to see when the Expander arrow is clicked. It will be the only item because Content isn't a container and you need to use something like a StackPanel if you have more than one child that you want to include in the expanded area.

Something like this:

      <Expander.Content>
          <StackPanel >
            <CheckBox Margin="2,4" Content=" Do This"></CheckBox>
            <CheckBox Margin="2,4" Content=" Do That"></CheckBox>
            <CheckBox Margin="2,4" >
              <CheckBox.Content>
                <StackPanel Orientation="Horizontal">
                  <Image Width="16" Source="DCP_1997.jpg"></Image>
                  <TextBlock Text=" View Profile"></TextBlock>
                </StackPanel>
              </CheckBox.Content>
            </CheckBox>
            <TextBlock TextWrapping="Wrap" Margin="3,30,0,0" 
          Text="Select a task from the list above." />
          </StackPanel>
        </Expander.Content>

to produce this result:

My Blogs Are Moving to New Site

Admin — Tue, 09 Dec 2008 00:13:00 GMT

VBCity will be looking very different soon, as we change to the new Community Server based model. In advance of that change, our blogs are moving to a new area.

From now on, you can view my latest blogs both here and at the new site here. Once the new site is fully up and running, all new blog items will be posted on the new area only.

All previous blogs from VBCity Bloggers will still be available and hopefully will continue to rank highly in search engine results.

How To Get the Icon from an Application

Admin — Fri, 28 Nov 2008 02:00:00 GMT

This question comes up every so often in the forums and it's one of those things that you'd think should be easy, but actually isn't. Well, it isn't until you know how - like most things in developer land. The question is usually something along the lines of "How can I grab the icon from an MS Word file?" The application may not necessarily be MS Word, but the that's the general thrust of it.

The only approach I have successfully used in this kind of scenario is the SHGetFileInfo API*. This API will grab the icon from an application.

Here's the way I do it: First, Import Runtime.InteropServices into your Windows Form.

Code Copy

Imports System.Runtime.InteropServices

Next, the API code, which goes at the top of the form, outside of any procedures:

Code Copy

    Private Structure SHFILEINFO
        Public hIcon As IntPtr
        Public iIcon As Integer
        Public dwAttributes As Integer
        <MarshalAs(UnmanagedType.ByValTStr, SizeConst:=260)> _
        Public szDisplayName As String
        <MarshalAs(UnmanagedType.ByValTStr, SizeConst:=80)> _
        Public szTypeName As String
    End Structure

    Private Declare Auto Function SHGetFileInfo Lib "shell32.dll" _
            (ByVal pszPath As String, _
             ByVal dwFileAttributes As Integer, _
             ByRef psfi As SHFILEINFO, _
             ByVal cbFileInfo As Integer, _
             ByVal uFlags As Integer) As IntPtr
    Dim hImgSmall As IntPtr 'The handle to the system image list.
    Private Const SHGFI_ICON As Long = &H100
    Private Const SHGFI_SMALLICON As Long = &H1

Note the two Constants at the end there being declared as Long. You'll usually find you have to tweak old API code to fix these kind of lines if you have Option Strict On.

To demonstrate this API in action, here is how I've structured it:

I have added a button (btnSelectFile) to the Form.
When this button is clicked, an OpenFileDialog is created to allow the user to select a file.
Once a file has been selected, the file name is passed to a function that will dig out the icon for that file type and pass it back.
For demo purposes, the Form's default icon will be replaced with this selected one.

Here is the code in the function that grabs the icon:

Code Copy

Function GetIcon(ByVal filename As String) As Icon
        Dim shinfo As SHFILEINFO
        shinfo = New SHFILEINFO

        'Get the small icon.
        hImgSmall = SHGetFileInfo(filename, 0, shinfo, _
          Marshal.SizeOf(shinfo), _
          SHGFI_ICON Or SHGFI_SMALLICON)

        Return System.Drawing.Icon.FromHandle(shinfo.hIcon)

End Function

And here is that function being called from a Button Click, the icon then being shown as the Form's icon:

Code Copy

  Private Sub btnSelectFile_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnSelectFile.Click
        Dim ofd As New OpenFileDialog

        If ofd.ShowDialog = Windows.Forms.DialogResult.OK Then Me.Icon = GetIcon(ofd.FileName)

End Sub

That's pretty much all there is to it, if you are happy to plonk the icon on the form like that. But in most cases you'll probably want something a bit more reusable. One easy way to store the grabbed icon is to put it in an ImageList.

Assuming that you are only going to deal with one icon at a time, you can do something like this:

Code Copy

Dim myIcons As New ImageList
myIcons.Images.Add(System.Drawing.Icon.FromHandle(shinfo.hIcon))

Now that you have that icon safely stored in the ImageList, you can access the ImageList in the usual way if you want to place the icon image elsewhere. And of course you can change the above code slightly to allow for more than one icon to be added to the ImageList and used as required.

Finally, if you need to switch the icon into Bitmap format you can use the handy ToBitmap method:

Code Copy

Dim bmp As Bitmap = System.Drawing.Icon.FromHandle(shinfo.hIcon).ToBitmap

It is possible then to save the Bitmap by using the Bitmap's Save method. However, I have found this to be a bit hit-and-miss, with it sometimes throwing a generic GDI+ error when I tried to recall it for use by means of the Image.FromFile method.

I hope that if you need to grab an image from an application that you find this article useful.

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

* There is the much more hopeful sounding ExtractIcon API which I have used to extract the icon of a currently running VB application, but haven't managed to port the logic over to the kind of file selection scenario described here.

WPF Missing In Action - The Button PerformClick Method

Admin — Sat, 15 Nov 2008 23:59:00 GMT

PerformClick is one of the many casualties of a move from Windows Forms to WPF. Of course, it's probably not something you would need to use often, but just in case you do then there is a way.

It's not a very intuitive way and - had it not been that I spotted the C# version of this trick in Adam Nathan's WPF book - I wouldn't be sat here writing this now. I'd still be searching endlessly to try and find the answer.

   In order to achieve this in VB, you need to do the following:

  Add a Reference to UIAutomationProvider in your Project.

  Add an Imports statement:
Imports System.Windows.Automation.Peers

  Add another Imports statement:
Imports System.Windows.Automation.Provider

  Use the following code snippet:
Dim buttonPeer As New ButtonAutomationPeer(Button1)
Dim invokeProv As IInvokeProvider = TryCast(buttonPeer.GetPattern(PatternInterface.Invoke), IInvokeProvider)
invokeProv.Invoke()

   The above code to be placed wherever you want to simulate the Button's Click. (Change the Button name as needed).

It did occur to me that this task might be a good candidate for a custom Command, using WPF's quite versatile Command abilities. However, I haven't got past the "wonder if that's a good idea?" stage. And to be honest, probably won't any time soon.

Whether you feel that it's necessary to go to the trouble of the Automation or the Command approach is of course entirely up to you. I have to admit to being tempted simply to move the action code out of the Button Click event and into a separate method that can be called from both the Button Click and other events. But then, I've never been much or a purist about these things.

WPF project for Background Colours

Admin — Sun, 26 Oct 2008 05:49:00 GMT

It is a little longer than I expected to get the the project that goes along with this post about background colours in WPF but as they say better late ....

The project can be downloaded from here.

The Ampersand and XAML

Admin — Sun, 26 Oct 2008 05:11:00 GMT

I got caught the other day with a "what the heck" moment.

I was trying to display "Mr & Mrs" as an Item in a ComboBox but it just was not happening.

I suppose that this would not have come to light if my computer was not slowing down when I opened the ItemCollection window in Visual Studio. It was so slow that I would type something then have to wait for a couple of seconds to show what I had typed. If I made a mistake I had to change it which would take more time, so I decided to just add the five combobox items in the XMAL itself.

As soon as I typed the item in, I got the squiggly blue line and the following error.

Which really threw me.

Being an old HTML boy from years past it finally hit me. XAML is a markup language and most, if not all, markup languages use the ampersand (&) for defining special characters and XML (which XAML is based on) is no different.

XAML has the same character entities as XML and one of these is for using the ampersand in markup.

Having refreshed my memory getting the desired result was an easy fix.

Which, when run, shows correctly in the ComboBox.

WPF MIA - Anchor, Alignments,Canvas and Margins

Admin — Sat, 25 Oct 2008 21:07:00 GMT

Continuing my look at features that seem to be Missing in Action (MIA) from Windows Forms, vbCity colleague Matt pointed out to me that the Anchor property seems to have disappeared.

I'm really pleased that this came up, because it gives me an opportunity to highlight just some of the massive flexibility you have in WPF Windows when it comes to layout.

So what does WPF have to offer that will work as well as Anchors do? Umm, that should probably read 'better than Anchors do', because let's face it, WinForms Anchoring doesn't always offer you the precise flexibility you want. But the short answer to the original question is: Lots!

I'm only going to cover a few examples here and then invite you to play with the ideas I have suggested. Using these, you can ensure that every control (or element, as we should properly call them in WPF) sits exactly where you tell it to, and stays anchored or not as the Window resizes, according to your wishes.

HorizontalAlignment, VerticalAlignment and Margins
These two properties are reasonably close to the Anchor properties in WinForms. HorizontalAlignment gives you the choice of aligning (read: Anchoring) to Left or Right. So you can see how they relate to Anchor Left and Anchor Right. However, WPF never does layout by halves, so you also have two more choices - Center and Stretch. I won't insult your intelligence by telling you what those additional settings do.

Here's an example that will anchor a button to the top right hand corner of a Grid.

<Button  Margin="0,5,5,0" HorizontalAlignment="Right"

        VerticalAlignment="Top"  >Button</Button>

The result you will get is:

Notice that there is a 5 unit gap to the top and right of the button. I carefully used the word "unit" there because old habits always want me to say 'pixel'. It isn't necessarily 5 pixels gap; WPF thinks in terms of 'device independent units', but in many common scenarios you can still think pixels.

The two gaps are set by the Margin property. "0,5,5,0" translated to:

0 for the Left Margin
5 for the Top Margin
5 for the Right Margin
0 for the Bottom Margin

Go ahead and tweak those settings to see how changes affect the position.

If you try this markup, run the project and then resize the Window, that button will stick like glue to its position at the top right.

Obviously, if you don't want any gaps then you can dispense with the Margin settings. This version uses the Left and Bottom settings only.

 <Button HorizontalAlignment="Left" VerticalAlignment="Bottom" >Button</Button>

Margins Only
If you want an element to expand (and reduce) as the containing Window or other container resizes then you can achieve this just by setting the Margin properties.

<Grid Background="Black">

     <Button Margin="20,50"  >Button</Button>

    </Grid>

Alignment and Width
Another combination you can try is to use one of the alignments, together with hard coding the Width or Height of a control. Usually you won't want or need to fix a height or width, but there may be cases where this works for you. Try something like this:

 <Grid Background="Black">

        <Button VerticalAlignment="Bottom" Width="90">

          Button</Button>

    </Grid>

And in case you were wondering - yes, you can also add settings for the Margins too, so that you can position it, for example, a set distance from the Bottom edge.

 <Grid Background="Black">

        <Button VerticalAlignment="Bottom" Width="90"

                Margin="0,0,0,15">

          Button</Button>

    </Grid>

I hope that by now you're starting to get the idea that WPF layout isn't going to miss the Anchor property any day soon! Combine the techniques shown above and you have a wide range of options.

Canvas
But we're not done here yet. If you want to contain an element inside a panel and be able to fix its relative position, you could use a Canvas. Check out this markup:

 <Grid Background="Black">

      <Canvas Margin="50,35" Background="Yellow">

        <Button Canvas.Left="12" Canvas.Top="3">Button</Button>

      </Canvas>

    </Grid>

This will net you the following, rather garish, result:

That button will remain 12 units from the left and 3 units from the top of that Canvas, no matter what else happens by way of resizing the Canvas, the Grid or even the Window.

I think that even these simple, single examples show a great deal of power and flexibility for positioning elements. Bear in mind that you can build up layers of containers and panels and elements inside each other - and control the placement of each of them individually in relation to its container.

While the familiar Anchor may be missing, I somehow think that once you become used to using these new techniques you won't actually miss it at all.

WPF MIA: BackColor, Background, Colors and Brushes

Admin — Fri, 24 Oct 2008 03:56:00 GMT

One of the things that first caught me out in WPF was the simple topic of colors. For example, let's say you want to reset the BackColor of a Form in Windows Forms.

Easy enough. This will do the job:

Code Copy

Me.BackColor = Color.CadetBlue

When it comes to WPF, you'll know that we are dealing with a Window, instead of a Form and have probably already picked up that BackColor is now Background. You can however, still use "Me" to reference the Window.

But if you were to try something like:

Code Copy

Me.Background = Color.CadetBlue
    ' or even
Me.Background = Colors.CadetBlue

you would be disappointed.

You would however get some help from Intellisense (at least with the second version). The error message tells you that a Color cannot be converted to a Brush. And there's the answer to the problem.

The Background property doesn't take a Color - it takes a Brush, which of course can, and usually does, have a color assigned to it. Don't forget though that you are not limited to a single solid color; there are many gradient, tile and image based options that you can choose when it comes to brushes in WPF.

So this code will work fine in WPF:

Code Copy

  Me.Background = New SolidColorBrush((Colors.CadetBlue))

Ah yes, I hear you say, but what about the theory that you should use XAML for the look and code-behind for the behaviour? Well, I can't disagree with you there and personally I would use:

<Window x:Class="Window1"

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    Title="Window1" Height="300" Width="300"

Background="CadetBlue">

where the Background property for the Window is set there in the XAML. However, there may well be times when you want the user to have a say in color choices and in those cases it can be easier to take the user's input and deal with it in the code-behind.

For example, if the user was empowered to enter values for the ARGB components then you might use an approach like the following:

Code Copy

        Dim col As New System.Windows.Media.Color
        '  In reality the values below could be
        ' selected by the user and passed in
        col = Color.FromArgb(214, 122, 52, 24)
        Dim br As New SolidColorBrush(col)
        Me.Background = br

It would also be quite easy to create a display in WPF where you bind, for example, sliders to the Brush that is used for the background. But I won't go any deeper into that just now, as this sub-set of blog items is meant only to help identify those missing WinForms favorites and repatriate them as WPF troops.

WPF: How To Hide the Minimize and Maximize Buttons

Admin — Wed, 22 Oct 2008 16:17:00 GMT

For some time now, I've been promising myself that one day I will create a list of what I like to think of as "WPF MIA" - those basic elements that I am totally familiar with in WindowsForms, but which somehow seem to have disappeared into thin air in WPF.

In many cases of course the tools are still there; it's just that the name has changed. Here's an example:

In Windows Forms, you can hide the Minimize and Maximize buttons by setting the MinimizeBox or MaximizeBox to False I guess that this is most people's favourite way of doing this. If you dig deeper into the Properties Window though, there is also the FormBorderStyle property.

I used to think that this property was only good for things like changing the border style, say, from 3D to single line. But actually if you choose FixedToolWindow or SizableToolWindow then you automatically get a Form that only has the close button - no Min or Max.

So what about WPF then? Does it have the same properties available?

If you've spent any time on WPF, you'll know that that's really a rhetorical question because you can almost guarantee that things will have changed. Now though you have a WindowStyle property which you can use to set the Window's border style, including showing or hiding the Max and Min buttons. To have those buttons hidden, you need to choose the ToolWindow option.

As far as I know, there isn't a property setting that will hide the individual buttons in in WPF. At first I found this a bit surprising. However, as I've become more familiar with WPF and its ability to morph its Windows into almost any conceivable style and shape, I can see that creating your own Window style is so easy that maybe those properties would have been almost redundant anyway.

Printing a Windows Foundation Presentation FlowDocument

Admin — Sat, 18 Oct 2008 08:05:00 GMT

I have just discovered the most compelling reason to port over any projects I have to Windows Presentation Foundataion (WPF) as well as only starting new projects as a WPF project.

The reason you ask? Well the answer is one word.

Printing

Being a File I/O guy, printing has almost always needed to be a part of most projects that I have written so this is a really big thing for me. Looking back printing with Visual Basic.NET was painful for me at times especially if the document spanned several pages and I don't even want to get into printing with pre .NET Visual Basic.
That, however, is the past and today we take a look at the present and future.

After creating a table in a flowdocument I got to thinking about being ability to print out the flowdocument.

The WPF PrintDialog class has two methods for printing. The two methods are PrintVisual and PrintDocument.

This post will deal with the PrintDocument method.

When you use PrintDocument you don’t actually pass the flowdocument that you want to print as a parameter, you use a DocumentPaginator object.

What the documentpaginator does is take the content of the flowdocument and breaks it up into multiple pages (if required) then passes the page(s) to the printer to be printed out.

After importing the necessary namespaces and declaring two Form level variables

I started out with the code to create a flowdocument that goes over more than one page I used the following code.

' Create the parent FlowDocument...
        flowDoc = New FlowDocument()
 
        Dim table2 As New Table()
 
        flowDoc.Blocks.Add(table2)
 
        table2.Columns.Add(New TableColumn)
        table2.Columns.Add(New TableColumn)
        table2.Columns.Add(New TableColumn)
        table2.Columns.Add(New TableColumn)
 
 
 
        ' Create and add an empty TableRowGroup to hold the table's Rows.
        table2.RowGroups.Add(New TableRowGroup())
 
        ' Add the first (title) row.
        table2.RowGroups(0).Rows.Add(New TableRow())
 
        ' Alias the current working row for easy reference.
        Dim currentRow2 As New TableRow()
        currentRow2 = table2.RowGroups(0).Rows(0)
 
 
        Dim v As New Image
        v.Source = New BitmapImage(New Uri("dice.jpg", UriKind.Relative))
        v.Height = 80
        v.Width = 80
 
 
 
        ' Add cells with content to the second row.
        currentRow2.Cells.Add(New TableCell(New Paragraph(New Run("Loan Report"))))
 
        currentRow2.Cells(0).ColumnSpan = 3
        currentRow2.FontSize = 50
        currentRow2.Foreground = Brushes.RosyBrown
        currentRow2.Cells(0).TextAlignment = TextAlignment.Center
 
        currentRow2.Cells.Add(New TableCell(New BlockUIContainer(v)))
 
        table2.RowGroups(0).Rows.Add(New TableRow())
 
        currentRow2 = table2.RowGroups(0).Rows(1)
 
 
 
        currentRow2.Cells.Add(New TableCell(New Paragraph(New Run(" For: Neil Knobbe, " & Now.Date.ToLongDateString))))
 
        currentRow2.Cells(0).TextAlignment = TextAlignment.Center
        currentRow2.Cells(0).ColumnSpan = 4
 
        table2.RowGroups(0).Rows.Add(New TableRow())
 
        currentRow2 = table2.RowGroups(0).Rows(2)
 
        currentRow2.Cells.Add(New TableCell(New Paragraph(New Run("Ammount Borrowed: Borrowed Variable" & vbCrLf & _
                                                                  "Monthly Payment: Payment Variable" & vbCrLf & _
                                                                  "Interest: Interest Variable" & vbCrLf & _
                                                                  "Duration: Duration Variable" & vbCrLf & _
                                                                  "Reason For Loan: Reason Varaible" & vbCrLf & _
                                                                  "Lender: Lender Variable" & vbCrLf & _
                                                                  "Loan Number: LoanNum Variable"))))
 
 
        currentRow2.Cells(0).ColumnSpan = 2
        currentRow2.Cells(0).Padding = New Thickness(10)
 
        ' Create and add an empty TableRowGroup to hold the table's Rows.
        table2.RowGroups.Add(New TableRowGroup())
 
        ' Add the first (title) row.
        table2.RowGroups(1).Rows.Add(New TableRow())
 
        ' Alias the current working row for easy reference.
        Dim currentRow As New TableRow()
        currentRow = table2.RowGroups(1).Rows(0)
 
        ' Add the header row with content, 
        currentRow.Cells.Add(New TableCell(New Paragraph(New Run("Date"))))
        currentRow.Cells.Add(New TableCell(New Paragraph(New Run("Balance"))))
        currentRow.Cells.Add(New TableCell(New Paragraph(New Run("Payment"))))
        currentRow.Cells.Add(New TableCell(New Paragraph(New Run("Interest"))))
 
        currentRow.Cells(0).Foreground = Brushes.RosyBrown
        currentRow.Cells(0).TextAlignment = TextAlignment.Left
        currentRow.Cells(1).Foreground = Brushes.RosyBrown
        currentRow.Cells(1).TextAlignment = TextAlignment.Left
        currentRow.Cells(2).Foreground = Brushes.RosyBrown
        currentRow.Cells(2).TextAlignment = TextAlignment.Left
        currentRow.Cells(3).Foreground = Brushes.RosyBrown
        currentRow.Cells(3).TextAlignment = TextAlignment.Left
 
        table2.RowGroups(1).Rows.Add(New TableRow())
 
        currentRow = table2.RowGroups(1).Rows(1)
 
        currentRow.Cells.Add(New TableCell())
 
        currentRow.Cells(0).ColumnSpan = 4
        currentRow.Cells(0).BorderThickness = New Thickness(0, 5, 0, 0)
        currentRow.Cells(0).BorderBrush = Brushes.RosyBrown
 
        Dim i As Integer
 
        For i = 2 To 25
            table2.RowGroups(1).Rows.Add(New TableRow())
 
            currentRow = table2.RowGroups(1).Rows(i)
 
            currentRow.Cells.Add(New TableCell(New Paragraph(New Run("Column " & i - 1 & " Entry - " & i.ToString))))
            currentRow.Cells.Add(New TableCell(New Paragraph(New Run("Column " & i - 1 & " Entry - " & i.ToString))))
            currentRow.Cells.Add(New TableCell(New Paragraph(New Run("Column " & i - 1 & " Entry - " & i.ToString))))
            currentRow.Cells.Add(New TableCell(New Paragraph(New Run("Column " & i - 1 & " Entry - " & i.ToString))))
 
 
        Next
 
        ScrollView1.Document = flowDoc

Which, once I applied the table to a flowdocument and set the flowdocument to be the document of my FlowDocumentScrollViewer,

gave me a table with 50 entries, shown in three columns, which I wanted to print.

Now that the flowdocument was ready to print all that was left to do was create instance of a WPF PrintDialog and enter the one line of code needed to print the document.

Yes you heard right, one line of code* to print a WPF flowdocument. How much easier can it get? (And I thought I was happy when the people at MS made reading the entire contents of a file into a single line of code for Visual Studio 2005. I am simple ecstatic about this change to printing!)

(* Note – Although you can accomplish printing with just this one line, there are a few gotchas that you will need to be aware of. I will touch on some of these in a bit.)

So, the magic line of code is:

Ok, I hear all you out there going "Ummm.... Neil that looks like 5 lines of code to me not one like you said." Which would be a valid statement and it is true there is a couple more lines of code.

Basically what I have done is put the print code in an If...End If statement which gives displays the printdialog to the user where they can choose their printer and print the document or cancel the print job all together.

All in all six lines of code to print out a single or multiple page document is nothing.

What is the code doing then?

As I mentioned earlier a new instance of a printdialog is created. The printdialog is the window that is shown where you can select which printer you want to print with and other printing options.

The printdialog is shown as a dialog window and if the user clicks the "OK" button, the flowdocument is cast as a DocumentPaginator object which is used as the first parameter of the printdialog’s PrintDocument. The second parameter of the printdocument is the name of the document being printed. This name is what is displayed in the print queue of the printer so you can uniquely identify what documents are lined up to be printed.

The Else portion of the If...End If statement handles if the user clicks the "Cancel" button. A simple message box is displayed letting the user know that the print job has been cancelled.

That in a nutshell is all that you need to do to print a flowdocument in a WPF application.

Now for the gotchas that caught me while I tried to print.

#1) Multiple columns. Let me tell you I this one really got me. When I first tried to print the flowdocument in the image above, I expected the print out to look like the window. Such was not the case. What I ended up with was the entire table printed out on two columns per page over the three pages* the printed document covered.

This was not quite what I was expecting, but is apparently the default behaviour without having set any properties of the document to match the printer. What I wanted was to have the table fill the entire width of the page.

(* Note - As a rather interesting side note here this is not what I got the first time I tried to print this flowdocument. My first results were rather disappointing and I was very disillusioned with what I thought was going to be a much simplified printing process. The image below is my first attempt at printing.

As you can see it ended up quite the mess. What happened was that all three pages of the flowdocument got printed in two columns on one page. (If you look real close at the left column you can see the header of the table in the background then the first 8 lines have been printed twice.)

I can happily report that the fault with this lies with the printer and not how the WPF printdialog sent the document to the printer. I have since tested several other printers and they all print as the multiple columns image.)

Getting back on track and printing the document on only one column.

The way to get around having multiple columns is to set the column width of the document to be printed prior to casting it as a documentpaginator object. This is a simple process and requires only one line of code.

What this code does is sets the width of document in the scrollviewer to be the entire printable width of the page. Now when the document is printed the table will span the width of the page.

#2) Page size. While perhaps not quite as important as multiple columns is getting the proper page size and margins for your printed output.

You can set the bounds of your document to be printed by setting three properties of the document. The three properties are the PrintableAreaHeight, PrintableAreaWidth and the Thickness.

The PrintableAreaHeight and PrintableAreaWidth properties are pretty self explanatory. The Thickness is what is used for the margin. The thickness can be set with a universal value which will be applied to all sides, or you can set pass different parameters for the margin on each side.

While it is not essential to set these three properties for printing it does ensure that your document fits the page or pages.

Summary

So, with adding in the few lines of code from the two gotchas, I finally was able to print out the report and have it look as I wanted it to.

The entire print code I used was:

There you have it a quick overview of printing in a WPF application. As I said it is much easier and I have my doubts if I will ever look at starting another WinForms application.

Tables in a Windows Presentation Foundation FlowDocument

Admin — Wed, 08 Oct 2008 07:24:00 GMT

vbCity Leader (and Microsoft MVP) Ged Mead showed how to create a FlowDocument in his article published on devCity.com.

I got the challenge recently to display a data inserted in a table in a flowdocument. So I embarked on my quest.

I knew that what I wanted could be done because some quick testing with XAML I was easily able to add a table to my flowdocument.

Which gives an output like the following.

My challenge, however, was that I needed to be able to do this with Visual Basic.NET code behind as the data that was to be displayed in the table was going to be read from a file.

I made my first mistake almost immediately. (Now that is probably not the best thing for me to admit when I am trying to convince everyone that I actually know what I am talking about, but hey, I am big enough to admit my mistakes.)

The mistake I made was trying to use the wrong table. I was able to create and insert the data from the file into the table I created with VB code, but when I tried to add the table to the flowdocument I couldn’t. No matter what I tried, I was just unable to add the table and after a couple of days, I finally gave up and asked for help. Microsoft MVP Jay Harlow quickly pointed me in the right direction.

What the problem was is that there are more than one table that is accessible for use in the .NET Framework. I was trying to use the table in the System.Web Namespace, but in fact I needed to be using the table from the System.Windows.Documents Namespace.

Once I was referencing the correct table, the whole project came together quite nicely.

(While the project I was doing required reading data from a file that will be outside the scope of this blog post. In this post I will just be showing how to hardcode data into a table in a flowdocument.)

The first thing that is needed is to Import the Namespace to give us access to use a table.

Next declare two form level variables. One variable is declared as a flowdocument and the other is declared as a table.

In the event you want to create the table in, I used the Initialized event of the form for this example, set the two variables to a new instance of a flowdocument and table respectively.

Now that there is a flowdocument and a table the table needs colums, rows and content for the table.

The columns are the first things to be added to the table. Columns are added to the collection, or array, of columns of the table. For this example I am going to add four columns to the table.

With the columns added, Rows can now be added to the table. Like columns, rows are also held in an array of rows. Where rows differ from columns is rows are actually part of RowGroups. You can have several rows in a rowgroup and more than one rowgroup in a table.

So to start a new rowgroup must be added to the rowgroups of the table.

and into that rowgroup a new row is added.

Although you still can’t see it if you were to look at the form itself, the table now has four columns and one row. Into the row Cells need to be added.

At this point there is a great deal of possibilities to how what the table is going to look like. While you can set some formatting for the table with changing the properties of the table and rows, you have much greater control over the look of the table by manipulating the properties of the cells.

For this table I want to have a header that stretches across the entire top of the table, so while I can have four cells in the row (I can do this because I added four columns to the table earlier) only one is going to be added to the row. The cell will then be made to stretch over the entire width of the table.

There is quite a bit going on in the above line of code. A new TableCell is added to the collection of cells of the row and to add content to the cell a new Paragraph is used as a parameter of the tablecell and a new Run of text is passed as a parameter of the paragraph.

After adding what is going to be the title of the table, some formatting can be assigned.

The first line of code above tells the cell to span the entire width of the four columns of the table. (If you have worked with tables in Microsoft Word think of this process to be like merging cells in a table.)

The second line sets the size of the font to make the text stand out as a title and the third line centers the text in the cell. (By default the text alignment of a table, row or cell is left.)

The fourth line of code makes the font bold.

The fifth line of code sets the colour of the text in the cell and the sixth line gives the cell a colour for the background.

If we add two more lines of code the table can be shown in the FlowDocumentReader.

The table is first added to the Blocks of the flowdocument that was declared at the beginning of our code then the flowdocument is assigned as the document of the FlowDocumentReader of the form.

(Note: Interestingly enough it does not seem to matter where you place the code to add the table into the flowdocument and make the document of the reader to be your flowdocument. The code can be added just after the declaration of the flowdocument and table or anywhere in the middle of the code that formats and populates the table. Personally I put these two lines at the very end prior to displaying the flowdocument.)

Now when the project is run, you can see the table starting to take shape.

Putting Headers for each column are next to be added to the table.

A new row is added to the rowgroup of the table then four cells are added to the row with content also being added to each cell.

You can see by the Index number of the rows that the new cells have been added to the second row. Like all .NET arrays the rows array of a rowgroup, as is the rowgroup itself, are zero based so if you need to remember that the actual row number is one higher than the index number.

Running the project shows that the columns now have headers.

The table is really starting to look like a table now.

A line under the column headers keeps the data in the columns separated from the headers. To accomplish this, a new row is added under the row of headers. One cell is added to the row and it will span the four columns like the title cell does. To make the line, the border property of the cell is going to be used. The top border of the cell will be made larger and given a colour.

To make the border thicker a New Thickness is applied to the cell. Thickness can either be set by passing a single parameter to the new thickness, which would give the same thickness to all sides of the cell, or you can pass four parameters and assign separate thicknesses to each side. While it does not make any difference to what I am demonstrating here, I have only assigned a thickness to the top border of the cell. I could have just as easily assigned a uniform thickness to the cell.

Now the contents of the table will be separated from the column headers by a red line.

With the formatting of the table set out, it is time to add some content into the table itself.

For this example I am going to use a For…Next Loop to populate the table.

Two Integer variables are declared. The first is used to keep track of the index of the row in the rowgroup. The variable is declared with a value of 3 because the first line that will be added in the loop will be the fourth element of the array of rows. The second variable is just used for adding content to each of the cells as they are added to the row.

In the loop the first line of code adds a new row to the table then the next four lines add the cells to the row and put some content in the cell. In this example the content of the cells in the row will just have the text "Number: 0" to "Number: 97".

In the last line the value of the variable j is incremented by 1 so the content number of the next row will be one higher than the last.

Now when the project is run the table is complete. The table starts with:

and six pages later going to:

Windows Presentation Foundation ToolTip

Admin — Wed, 08 Oct 2008 06:39:00 GMT

Once again it seems that I had what I thought was a great idea only to find out that someone else had it before I did.

I don’t even know how I got to thinking about ToolTips and how boring they look, but I did and that got me to wondering what could be accomplished with Windows Presentation Foundation (WPF).

What I eventually ended up with was using a Border which I would create custom messages in and display when the mouse was hovered over the object that the ToolTip was for.

All in all I was fairly pleased with how it all looked and worked though it was kind of fiddly to implement. I wasn’t really sure, however, how to incorporate this tooltip idea into an application I did want to use it.

That was, however, before I found out about the versatility of a WPF tooltip.

In WPF, the tooltip is actually just a container like a panel or grid and pretty much anything that you can put into a container you can now use in a tooltip. This expanded capability leads to endless possibilities for how a tooltip looks and how the user can now interact with it.

We all know how boring tooltips look in a WinForms application.

With just a few lines of code, this plain tooltip can be transformed into something a little more visually exciting.

The tooltip in the next image was formatted with just six lines of code.

The code for this was pretty straight forward.

A gradient was applied to the background of the tooltip. Creating a gradient colour is the same process as creating a gradient for anything in a WPF application. You can have as few as two colours up to a virtually endless number of colours. A gradient is also applied to the border of the tooltip as well.

The thickness of the border was increased so the colouring is more noticeable.

The content is filled with what we wanted to have the tooltip say and added a drop shadow effect to give the tooltip a little bit of a 3D effect.

The last property that is set is the Placement property. The placement property allows you to set where the tooltip is displayed in relation to the control that it is for. Some of the positions that you can place the tooltip are Top, Left, Right and Bottom. You can also set an Absolute or Relative position for the tooltip.
The last thing to do is set the tooltip that has just been defined as the tooltip of the control it is to be displayed for.

In addition to being able to customize the tooptip itself I mentioned earlier that you can place WPF content into the tooltip itself. One drawback to putting WPF content into a tooptip you do still will see the thin border of the tooltip behind the WPF content. I’m sure that there must be a way to get rid of the border, and with Vista it is not as noticeable, I just have not found the way to do it yet.

So with this in mind we will forge ahead with making an even more visual tooltip.

The first component required for creating a tooltip for WPF content would be some sort of container. In this example I am going to start with a StackPanel.

In the stackpanel there is going to be some text and an image so the code is going to start with declarations for the three objects.

Add some formatting to the stackpanel. In this case there are only two changes which are going to be applied to the stackpanel. A LinearGradientBrush is going to be applied to the background and the Orientation of the stackpanel is also set.

For the Image there are just three properties that are going to be set. The source, height and width of the image are defined.

For the textblock the content is set as well as some text formatting and the text is also centered in the textblock.

All that is left now is to add the image and textblock to the stackpanel then apply the stackpanel to be the tooltip of the textbox on the Form.

All this work now gives a much more fancy tooltip, looking like the following image.

So you can see that the boring old tooltip is now a thing of the past.

This post has only scratched the surface of what can be done with a tooltip in a WPF application. I plan on investigating this tool much more to see just what can be done with it.

You will need to keep in mind that you can’t put content into the tooltip that can have user interaction because the tooltip can’t get focus. If you put something like a button in a tooltip, which you can do with WPF, the click would just go through the button and click onto the control on the form.

Object Initializers - A New Perspective

Admin — Thu, 28 Aug 2008 14: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.