Pedro Silva's Blog : C Sharp

WpfAboutBox: Dialog Layout and Styles

PedroSilva — Fri, 08 May 2009 20:40:00 GMT

I wanted to make an AboutBox that is as easy to use as the one that comes with Winforms. But, I also wanted to make use of some of the cool new UI capabilities in WPF and make it look a little snazzier than the default WinForms one… Below are the two different AboutBoxes:

As you can see the WPF one makes use of some nice gradients and coloring that is easy to do with XAML. And, I adjusted the layout to look like About boxes that you see in many professional applications today. The XAML for this is very straightforward and makes heavy use of the StackPanel for laying out the WPF controls. The following listing is the code to make this dialog (listing from AboutBoxSimple.xaml):

<StackPanel x:Uid="displayArea" Style="{StaticResource DisplayAreaStyle}"

DataContext="{StaticResource aboutProvider}">

</StackPanel>

<Label x:Name="info" x:Uid="info" Style="{StaticResource ParagraphSeparator}"

Content="Product details:" />

<TextBox x:Name="description" x:Uid="description" Text="{Binding Mode=OneTime, XPath=Description}"

Style="{StaticResource ReadOnlyDescStyle}" />

<Button x:Name="okButton" x:Uid="okButton" Style="{StaticResource OkButtonStyle}"

Content="OK" />

<Hyperlink x:Name="hyperlink" x:Uid="hyperlink" NavigateUri="{Binding Mode=OneTime, XPath=Link/@Uri}" Style="{StaticResource LinkLabelStyle}"

Hyperlink.RequestNavigate="hyperlink_RequestNavigate">

</Hyperlink>

</Label>

</DockPanel>

</StackPanel>

Looks pretty straightforward… lots of Labels, a Button, an Image, and a Textbox with a few StackPanels to do some fancier layout. The StackPanel just makes sure each child control in it is stacked one on top of the other (for vertical panels). One interesting “control” you’ll notice is the HyperLink control that’s used for the License link… I described how to make that work in an earlier post.

You’ll notice that there’s no styling information (colors, sizes, fonts, etc) in this section. All of that is done through WPF Styles. This is similar in concept to styles in HTML. You define a style with an id, and then use it on the controls that you want that style to apply to. You’ll notice that many of the controls above have a Style attribute assigned. This is what connects a style to this control. But, where are styles defined… well they can be defined in multiple places… in a resource for this window, as an application resource, or as a separate resource dictionary file that can be included in other files. For this example, I’ve just included the resources in this XAML file. The following is a list of the resources used for the AboutBox.

<Window.Resources>

</Style>

<Setter.Value>

</LinearGradientBrush>

</Setter.Value>

</Setter>

</Style>

</Style>

</Style>

</Style>

</Style>

</Style>

</Window.Resources>

The <Style> tag allows you to put a key for each style, which is then used when assigning it to a control. You can also specify a TargetType, which tells us what type of controls this style can apply to. If you try to apply a style to an inappropriate type, you’ll get an error (but you can also target a base class, like Control, that would affect multiple types). Then, the body of the <Style> is just a list of <Setter> tags with properties and values that you want to set for this style. And, as you can see from the BackgroundStyle, some of the Setters can be complex types like gradients that require setting more than just a single value. Without this information, the layout of the controls XAML would be pretty spread out and not very colorful. Also, you may wonder why none of the Labels in the listing specify a Style attribute at all. This is because you can use a Style without a Key specified, in that case, that style applies to all types in this context (in our case this dialog). So,

</Style>

applies to all labels in the About box. This is handy because we don’t have to put that Style attribute on every Label control on the dialog.

The reason to use Styles is to separate the structure of your layout (controls, panels, etc) from the UI stylings for them. This makes it easier to maintain and change colors, fonts, and spacing. Also doing it this way, allows you to do skinning by completely replacing these styles with one that have the same key, but have different style properties set (will look at that in an upcoming post). For a more detailed description of how the Style tags work, I highly recommend the WPF Unleashed book.

One thing to note… in Visual Studio 2008, it’s a little difficult to work with styles in resources because the XAML designer doesn’t recognize them. So, if you select a control with styles, you won’t see the properties set within the style. And, changes you make through the property grid will be applied to the control, not the style. But, the power of using styles makes it worth doing, even despite this.

So, far the AboutBox has been completely done without writing any C# code… pretty cool. The only code I did have to write for this simple About box is to handle the Click event to navigate the HyperLink’s URI.

This topic has been all about layout and XAML. You’ll notice in the XAML above all of the Content sections don’t have the text that is displayed in the dialog… actually all they have is this funky syntax {Binding}. That’s because it uses databinding to retrieve the data that is displayed in the controls. We’ll talk about databinding in the next post…

Download

I’ve attached a ZIP file to this post with the project that I created for testing About boxes. This has all of the code for three different types of About boxes, but this article just discusses AboutBoxSimple.xaml and AboutBoxSimple.xaml.cs). I’ll be describing interesting parts of all of them in upcoming posts.

WpfAboutBox: Intro

PedroSilva — Thu, 07 May 2009 06:26:00 GMT

I've been testing out some of the different possibilities in WPF with a sample AboutBox -- every program has one and they're not overly complex (so they make a good starting point). Also, for those of you WinForms-turned-WPF devs out there, you've probably noticed that there's no WPF equivalent of the AboutBox item template that is available for WinForms projects. So, providing one may actually be useful for some of you out there.

From a learning perspective, I've been playing around with different types of layout and some databinding. And, my WpfAboutBox has been a good tool for learning these things.

My plan going forward is to:

Publish some posts with interesting bits I've learned so far... (actually some of my earlier WPF posts this month have come from this work).
Create an item template for a WpfAboutBox.
Port this over to Visual Studio 10 when Beta1 releases.
Convert the item templates to extensions that can be published online and installed through the new Visual Studio Extension Manager.

I'm hoping this will help me learn more about WPF and perhaps show you a very cool new feature of Visual Studio 10.

Programmatic Access to XmlDataProvider

PedroSilva — Mon, 04 May 2009 20:30:00 GMT

It’s pretty easy to set up an XmlDataProvider as a resource in your WPF application. This lets you databind controls to XML data islands pretty easily. The following XAML puts an XML data island into my application.

<Application.Resources>

<x:XData>

<Title>About WPF AboutBox[xml]</Title>

<Product>Sample WPF AboutBox[xml]</Product>

<Company>Microsoft Samples[xml]</Company>

<Description>blah, blah, blah

</Description>

<Link Uri="http://blogs.msdn.com/pedrosilva">License Terms</Link>

</ApplicationInfo>

</x:XData>

</XmlDataProvider>

</Application.Resources>

This embeds the XML into the application as a resource. It is also possible to reference a loose XML file of the same structure (if you’d prefer)… Using the following syntax:

This all works pretty smoothly when binding in XAML because it can be used as a StaticResource or DynamicResource. And, particular properties can be bound by their XPath equivalent. I’ve used this for a couple of quick projects without much trouble, but I ran into an issue when trying to access this XML data island programmatically.

When using the following code, the provider.Document unexpectedly returns null:

XmlDataProvider provider = App.Current.TryFindResource("aboutProvider") as XmlDataProvider;

if (provider != null)

{

XmlDocument doc = provider.Document;

...

}

This is because the document hasn’t been loaded correctly. And, it’s configured to be loaded asynchronously, which poses a little bit of a problem in this code. There are two work-arounds I found to make this function as expected.

In XAML, you can set the following properties appropriately so that load happens as expected (notice it’s the only difference from the XAML specified above):

You can also do it in code, as follows:

XmlDataProvider provider = App.Current.TryFindResource("aboutProvider") as XmlDataProvider;

if (provider != null)

{

provider.IsInitialLoadEnabled = true;

provider.IsAsynchronous = false;

provider.Refresh();

xmlDoc = provider.Document;

}

In the code that I’m using, I’ve preferred to go with the XAML definition of it, as that seems to work more consistently than setting the properties programmatically.

A WPF Dialog Window

PedroSilva — Tue, 28 Apr 2009 00:24:00 GMT

I’m continuing to work through learning more about WPF and XAML. I was trying a simple dialog and noticed that it didn’t look like typical Windows dialogs… for example, all WPF windows have an icon, but if you look at dialogs in most apps (and what WinForms produces), they don’t have a visible icon and system menu.

At first, I thought I’d missed something pretty obvious but after a several web searches and questions to some folks, it turns that’s the default window behavior in WPF. So, I decided to put together a class to expose what a typical dialog looks like.

First, the DialogWindow class derives from Window class. And, it exposes a couple of new dependency properties to control a couple of dialog behaviors:

· IsSystemMenuVisible – to show/hide the system menu.

· IsHelpButtonVisible – for context help button on dialog.

Then, we override OnSourceInitialized to set additional window styles when this window is being initialized.

/// <summary>

/// Sets the appropriate window style for the dialog window based on the

/// IsSystemMenuVisible and IsHelpButtonVisible properties.

///

/// Note: this makes several calls into native Windows methods to deliver

/// this functionality. NativeMethods is a wrapper for native Windows

/// calls.

/// </summary>

protected virtual void SetWindowStyle()

{

// Gets a window handle for this dialog window.

WindowInteropHelper wih = new WindowInteropHelper(this);

IntPtr hwnd = wih.Handle;

// Gets the current windows StyleEx value.

int windowStyle = NativeMethods.GetWindowLongPtr(hwnd, NativeMethods.GWL_EXSTYLE).ToInt32();

// Turns modal dialog frame on/off depending on whether we want to show

// the system menu.

if (IsSystemMenuVisible)

{

windowStyle &= ~NativeMethods.WS_EX_DLGMODALFRAME;

}

else

{

windowStyle |= NativeMethods.WS_EX_DLGMODALFRAME;

}

// Turns context help on/off for the dialog depending is we want it shown.

if (IsHelpButtonVisible)

{

windowStyle |= NativeMethods.WS_EX_CONTEXTHELP;

}

else

{

windowStyle &= ~NativeMethods.WS_EX_CONTEXTHELP;

}

// Now, sets the new windows StyleEx value.

NativeMethods.SetWindowLongPtr(hwnd, NativeMethods.GWL_EXSTYLE, new IntPtr(windowStyle));

if (!IsSystemMenuVisible && this.ResizeMode == ResizeMode.NoResize)

{

// Note: this is a workaround for a WPF bug. When NoResize is chosen,

// the system menu doesn't get set up correctly. The code below disables

// the appropriate system menu items in this case.

IntPtr hmenu = NativeMethods.GetSystemMenu(hwnd, false);

NativeMethods.EnableMenuItem(hmenu, NativeMethods.SysMenuPos_Maximize,

NativeMethods.MF_DISABLE | NativeMethods.MF_BYPOSITION);

NativeMethods.EnableMenuItem(hmenu, NativeMethods.SysMenuPos_Minimize,

NativeMethods.MF_DISABLE | NativeMethods.MF_BYPOSITION);

NativeMethods.EnableMenuItem(hmenu, NativeMethods.SysMenuPos_Size,

NativeMethods.MF_DISABLE | NativeMethods.MF_BYPOSITION);

NativeMethods.EnableMenuItem(hmenu, NativeMethods.SysMenuPos_Restore,

NativeMethods.MF_DISABLE | NativeMethods.MF_BYPOSITION);

NativeMethods.DrawMenuBar(hwnd);

}

The bulk of the interesting code is in the SetWindowStyle method. This method makes extensive use of calls to unmanaged code to expose the functionality we want. If we don’t want to show the system menu, we turn on the WS_EX_DLGMODALFRAME (this gets rid of the icon at the top left of the dialog window). I also tried turning off the WS_SYSMENU style, but this not only got rid of the system menu icon, but also gets rid of the dialog’s Close button.

Then, if we want the help button to show up, we turn on the WS_EX_CONTEXTHELP flag.

Even though the system menu icon isn’t shown, the system menu itself will still come up – when a user right clicks on the dialog title bar, or press ALT+SPACE. This is typical dialog behavior. However, in this case in WPF, there appears to be an issue, because that system menu comes up but the menu items aren’t always in the right state. Specifically when the ResizeMode is set to NoResize, the sizing system menu items are still enabled… this isn’t right. So the remainder of the code in SetWindowStyle, disables the appropriate system menu items.

Since I use quite a few native Windows APIs to make this work, I implemented a NativeMethods class that wraps the entire managed-native interop. And, I got most of this code from pinvoke.net (it’s very helpful for this kind of thing, in case you aren’t already familiar with the website).

There you have it… A dialog window that behaves like most Windows dialogs. It’s easy enough to create one of these dialogs:

<my:DialogWindow x:Class="WpfHelpersTestApp.TestDialog"

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

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

xmlns:my="clr-namespace:WpfHelpers;assembly=WpfHelpers"

Title="TestDialog" Height="200" Width="200" ResizeMode="NoResize" ShowInTaskbar="False">

<Grid>

</Grid>

</my:DialogWindow>

TestDialog test = new TestDialog();

test.IsHelpButtonVisible = true;

test.ShowDialog();

Notice that you can use XAML to create an instance of the new DialogWindow class, rather than the default Window that is usually generated. And, this generates the appropriate code for you. This is definitely cooler than what you would have to do in WinForms.

WPF LinkLabel

PedroSilva — Sat, 18 Apr 2009 01:30:00 GMT

WPF doesn't have a built in LinkLabel control as you'd find in WinForms. But, I have found a couple of neat ways of doing one in WPF. The first was creating a new WPF control that derives from Label and then adds functionality to have it behave like a hyperlink. While this will certainly work, it's more work than I was hoping that it would require.

Luckily, I ran across this post by Alessandro that composed a LinkLabel from a WPF Label control and a HyperLink object. This was done completely in XAML so no custom code was needed to create this behavior. And, the best part is that done this way, I was able to use databinding to set the text of the hyperlink and the the URI that would get launched when the user clicks it. Very cool... :)

The XAML snippet below shows how to define the LinkLabel composite and use databinding on its pieces (this binds to some simple XML that provides the link text and URI):

<Hyperlink x:Name="hyperlink" x:Uid="hyperlink" NavigateUri="{Binding XPath=Link/@Uri}"

Hyperlink.RequestNavigate="hyperlink_RequestNavigate">

</Hyperlink>

</Label>

The only code I had to write was to handle the navigation event for the HyperLink, and then launch your favorite internet browser in response.

private void hyperlink_RequestNavigate(object sender, System.Windows.Navigation.RequestNavigateEventArgs e)

{

string uri = e.Uri.AbsoluteUri;

Process.Start(new ProcessStartInfo(uri));

e.Handled = true;

}

One interesting thing I noticed is that you can either handle the Click or RequestNavigate event. If you handle RequestNavigate, the event only gets fired if you have a valid URI defined. Otherwise, the event isn't even fired. On the other hand, the Click event is always fired, so you need to put in error handling for invalid URIs. So, I'm going to tend to use RequestNavigate because it simplifies coding the event handler.

An old friend talking about Perf

PedroSilva — Thu, 16 Apr 2009 04:14:00 GMT

I was just reading over some blogs and ran across a couple of interesting topics on usage and perf on an Immutable Collection in the .NET runtime. Turns out to have been written by an old friend and collegue - Jared. He's always written about some interesting topics and good to see that hasn't changed.

Testing When Exceptions Are Expected

PedroSilva — Mon, 24 Sep 2007 20:27:00 GMT

Been thinking about and looking at unit testing a lot recently. And, one of the items that came up was how do you test for expected exceptions to make sure that they're being thrown correctly. So, I wrote of few tests that did just that and noticed how similar they were, so I decided to create a helper method that exposed this test for easy use in all of my tests. These examples are all using the unit test framework that's part of VSTS, but the concept could be used for other C# based unit test tools.

The method uses an anonymous delegate to allow the caller to provide the code that should throw the exception, and wraps all the exception handling and test validation around it in the helper. The following is the code for the exception testing method:

namespace BlogLibraryTests

{

/// <summary>

/// Helper class that provides methods for helping unit test development, like handling

/// expected exceptions and serialization of classes.

/// </summary>

internal static class UnitTestHelper

{

#region Exception Handling Helpers

public delegate void ExceptionTestDelegate();

/// <summary>

/// Tests method for an expected exception being thrown.

/// </summary>

/// <param name="del"></param>

/// <param name="exception"></param>

static public void TestException(ExceptionTestDelegate del, Type exception)

{

try

{

// Call the delegate, fail the test if it doesn't throw an exception.

del();

Assert.Fail("Test should have thrown exception " + exception.ToString() + ".");

}

catch (AssertFailedException)

{

// If it's a failed assert, then just rethrow because it's our failure above.

throw;

}

catch (Exception e)

{

// Test that the method threw the exception that we were expecting.

Assert.IsInstanceOfType(e, exception, "Exception is not of the expected type.", exception.ToString());

}

#endregion

}

The code above will ensure that an exception was actually thrown, or fail otherwise. And, if there was an exception, that it's the type of exception that we were expecting. Not an overly complex amount of code, but very repetitive for every method that you're testing that throws an exception.

Then calling it is just a matter of providing a delegate with the code that should throw the exception and the expected exception type:

/// <summary>

///A test for NamedElement (string)

///</summary>

[TestMethod()]

public void ConstructorTest()

{

// Test with valid name string.

string expected = "Foo";

string name = expected;

NamedElement target = new NamedElement(name);

Assert.AreEqual(target.Name, expected, "NamedElement(name) didn't initialize correctly.");

// Test with null name string.

UnitTestHelper.TestException(delegate() { target = new NamedElement(null); }, typeof(ArgumentNullException));

}

As you can see it makes for compact test writing and makes it easy to create a bunch of tests that ensure that your code throws the appropriate exceptions.

List of WinForms and C# Links

PedroSilva — Mon, 06 Mar 2006 20:40:00 GMT

There's been lots of WinForms and C# related content posted recently, and I have a list of things that I had meant to blog about, but never got around to. I'm going to post of list of some of these, so I can clear my backlog, keep track of them, and let other folks know about them...

Priority Queue: A priority queue using the skip list data structure.
XmlGridControl: this program uses code generation and CodeDom manipulation to edit XML data in the PropertyGrid.
Page Turn Effect: This article demonstrates how to use GDI+ to create a page turn effect.
TabControl Owner Drawn: creating composite custom controls with design-time support.
Extended ListView: An extended ListView control that can show multiple images on subitems, lets the user edit subitems with user-defined controls, contains boolean subitems and can columns can be sorted by date, number and string.
NumberPicker Control: a control that allows for easy number entering.
ToolStripColorButton: a color picker that is parented on a WinForms ToolStrip.

Check Out Gel Buttons for Winforms

PedroSilva — Wed, 01 Mar 2006 22:40:00 GMT

Chris Jackson has two posts about Gel Buttons that he's created for WinForms. They look really good and implement design-time support, so they're good examples on how to do that as well.

Not sure if there are any more parts to this, but so far they've been interesting posts.

Using 'Open With' System Dialog in C#

PedroSilva — Wed, 22 Feb 2006 22:05:00 GMT

Vivek has a project where he's written the interop layer to access the Windows shell's 'Open With' Dialog -- the one where you can associate a file extension with the application that should open it. It's a dialog that you may find useful in one of your applications, but isn't supported in the .NET libraries.

Having the interop and marshalling code, lets you call ShellExecuteEx, which you may find other uses for.

Using XBox 360 Controller in C#

PedroSilva — Wed, 15 Feb 2006 21:46:00 GMT

Here's a very cool sample that uses Managed DirectX to support input from the new XBox 360 controller in a simple Windows Form in C#.

Paul Stubbs : MDX: XBOX 360 Controller Windows Forms Application

[via Greg]

Radio Button in a .NET 2.0 MenuStrip

PedroSilva — Fri, 10 Feb 2006 02:39:00 GMT

I just ran into a problem doing this and found a great post about how to work around it. It appears that the MenuStrip doesn't support radio button items be default, but you can create a radio button effect by using the ToolStripMenuItem.Checked property and some drawing.

Minimize to System Tray Revisited

PedroSilva — Fri, 03 Feb 2006 19:51:00 GMT

Earlier in the week, I posted about a project that implemented system tray support for .NET applications. That seems like a good project, but it's a bit complicated.

I was just trying to add this functionality to an app that I've been playing around with, and I found another sources that has a more straight-forward way of doing it. This Developer.com article gives a very clear step-by-step process for minimizing a . NET application to the system tray. It only took about 5 minutes to implement after I found the article (that took significantly longer).

Using My Namespace for Splash Screen

PedroSilva — Thu, 02 Feb 2006 19:43:00 GMT

I posted earlier about using the My namespace in VS 2005 to create a single instance application in C#. You can also do a similar thing to use the My functionality for displaying a splash screen when your .NET application is loading.

Here is Tyler's post on how to do this in VB, but if you include Microsoft.VisualBasic reference into your C# project, you should also be able to get this to work for C# WinForms projects. Unfortunately, there isn't the same support for it in the C# Project property page, but you can do it in code. I'll try to code this up and post it here in C#, when I have a chance.

Couple of Cool Utility Libraries

PedroSilva — Wed, 01 Feb 2006 19:56:00 GMT

I saw these two posts on Greg's blogs, and they look very intriguing: FileHelpers and Screen Grabbing. These two libraries appear to be very useful - who doesn't need simplified file read/write functionality. And, the screen capture one is cool because it wraps some Win32 APIs for screen capture and give .NET developers easy access to that functionality (without having to do the interop yourself).