WPF - Point an Image to an Embedded Resource

This post has been moved to here. Thank you.

WPF - Non-Rectangular Window Sweetness

Recently, I have been working on a small WPF project. It is truly an exciting project and I hope to provide more details on the specifics later. Regardless, I learned something really cool about WPF while working on this project that I felt I needed to share.

My WPF application is not an archetypal rectangular window. It has a very well designed looking interface that really makes the application look nice. One of the distinguishing features is a large image in one of the corners of Window. As an illustration, imagine the application window looking like a more complicated version of the following:



I wanted to ensure that users could only drag the window if they were clicking within the bounds of the window. This means I needed to take into account the area occupied by the green ellipse. I learned how to create non-rectangular windows through this article.

I knew I could use the Path element to define the bounds of my window. However, the following discovery pleasantly surprised me. I was able to use a graphic, which was already created by a graphic designer, and simply make the background of the image file transparent. WPF automatically created the bounds of the window tightly bound AROUND the image.

This made my life significantly simpler. I was afraid I was going to be tinkering with Paths all day long. Very sweet.

My book "Silverlight 1.1. in Action" is coming along nicely. There should be some content available for consumption soon. Thanks for reading!

WPF/E - A basic WPF/E User Control

UPDATE - 05.05.2007 - The content of this post is no longer valid with the 1.0 beta release of Silverlight. The updated post and source code can be found here.

Recently, I wanted to learn about WPF/E so I created an ASP.NET User Control that takes the images from a specified directory and rotates through them and displays their reflection. I will admit, this posting is a bit light on pure information, however, I still wanted to share what I learned and the code I wrote. If you have any questions, please post a comment and I will be glad to answer them. (you can get the source code here):

I am not saying this is the best how-to on this type of thing, in fact, there are several improvements that can be made to the implementation. Rather, I created this as a proof-of-concept for myself, so I thought I would share what I learned along the way.

• I was pretty impressed with the ease in using this technology. If you are familiar with JavaScript, you are going to find it easy to work with WPF/E. A long time ago, I learned ActionScript. It's mediocre, but personally, I would rather work with a widely used language such as JavaScript when developing. I'm very thankful the WPF/E team decided to use JavaScript instead of trying to develop some other new scripting language.
• I really appreciated the fact that because WPF/E is in open text platform (it uses xml and JavaScript), the installation requirements fall on the client side. This was great because my hosting service doesn't have .NET 3.0 components installed, yet I was still able to deploy this sample.
• I actually used the Microsoft Expression Blend Beta 1 for the graphics implementation. I was extremely pleased to see that I had to make ZERO changes to the xaml in order to get it to work within WPF/E. Very slick.
• I had some difficulty deploying the application because the .xaml MIME type was not registered correctly on the hosting server. I do not own the server so I could not see what had happened. Shawn Wildermuth pointed out that sometimes you can have success deploying an application by using the .xml extension in place of .xaml. This is useful if you are having difficulty in getting .xaml registered as a mime-type. This little tip allowed me to get the WPF/E control you are seeing above deployed.

I plan on presenting on WPF/E in the Louisville, KY and Indiana geographies over the next couple of months. So if you're in the area and interested in this technology, please view the user group websites for more information.

once again, the source code is here if you would like it.

P.S. I just made the cut-off for my one-a-week posting goal by 27 minutes :)

WPF - What's the difference between XBAPs and WPF/E Applications?

I was recently trying to determine what the differences are between XBAPs and WPF/E applications. At first glance, they are both browser based solutions, so I was wondering about what the potential catch was. If you (the reader) have/know of any more please let me know and I will gladly update this posting. At this point, this is a list of some of the core items I've found:

• WPF/E Applications
  • Are cross-platform ready (Mac OS X and Windows)
  • Do not require the client to have the .NET 3.0 runtime. Instead, WPF/E applications run within a browser plugin.
  • Do not support code-behind
  • Rely on JavaScript


• XBAPs
  • Require the client to have the .NET 3.0 runtime components installed.
  • Are not cross-platform enabled. They will only run on Windows machines.
  • Support code-behind
  • Must run within IE (or use the IETab plugin for Firefox)

In my personal opinion, In general, I intend to use the technologies in the following environments:

WPF	XBAPs	WPF/E
Desktop solutions	Intranet Applications	Internet Applications
	Organization specific gadgets	General purpose gadgets

In general, WPF/E provides a more portable solution while currently sacrificing some of the functionality that XBAPs provide. In addition, XBAPs provide a slightly better developer experience simply because debugging JavaScript code can be somewhat tedious in comparison to debugging some code-behind pages.

How do you intend to use these technologies? I look forward to your comments.

WPF - How to distinguish a Grid from a Table

Recently, while perusing the WPF reference documentation, I noticed that WPF provides both a Grid and a Table control. I was very interested in comparing and contrasting the two as initially, I believed the two were almost synonymous. However, neither control provides the complete functionality of the other. This posting will help you learn how to distinguish between a Grid and a Table. Alot of this information is available from the Grid definition page on MSDN.

A Grid provides the following features over the Table:

• Element can be inserted by row and column indexes.
• Content can be layered within a single cell.
• Children can be relatively positioned to an upper-left corner of a cell

A Table provides the following features over the Grid:

• Built-in support for paging
• Built-in support for table headers
• Built-in support for table footers.

Essentially, a Grid is used for Layout and a Table is used Data. If you know of other differences, please post them in the comments and I will be glad to update this post.

WPF - How to Programmatically Work With Attached Properties

The purpose of this post is to explain how to programmatically manipulate attached properties. I recently learned about them from the XAML side, however, I began to question how to use them from actual code. I really like the fact that XAML essentially maps Objects-to-Elements and Object Properties-to-Element Attributes. Then I saw these attached properties and I had to do some investigating to figure out how to manipulate these types of values from code. It's actually pretty easy, but you have to do it once to know how to do it. So I thought I would share my new found knowledge. The code used in this posting is available here. For an overview of Attached Properties, go here.

As a proof-of-concept, I created an application that simply displays a ComboBox that displays the available columns. The user can select a column and press the "Update" button. When the "Update" button is selected, the ComboBox will move to the selected column. The application looks like the following (I know it's ugly, but I've also been playing with some of the LinearGradientBrush stuff).

The XAML code that is of interest looks like the following (please bear in mind this is just a snippet and not the whole thing):

The Attached Properties in the code snipped used above are Grid.Row and Grid.Column. These properties define where in the grid the ComboBox is displayed. In order to set the attached property from the code behind, I had to essentially use 1 (yes one) line of code in the Click event of the Button. That line of code looks like the following:
Grid.SetColumn(ColumnComboBox, selectedIndex);
selectedIndex is just an integer set from the selected value of the combo box.

The "magic" occurs because Attached Properties essentially call static methods of an object. The static method is always named in the same manner. It is defined as ObjectType.SetNameOfProperty. So from the example, the ObjectType is Grid and the NameOfProperty is Column. Pretty kewl.

Windows Presentation Foundation (WPF) - Why should I use it?

The "why" question was recently asked within the WPF Forum. It is an extremely valid and important question. I think it would be hard to adequately answer this question within a single blog post. However, when trying to explain "why" something is important, I try to stick to a "2-minute" rule. I pretend that I have two minutes to get my point across.

I really believe that WPF spans beyond just eye-candy (though it does let you make some pretty slick looking stuff) and provides value for all types of applications. This post is far from a complete answer to the "why" question, for more information, I would recommend this great article . However, let's pretend I have two minutes to explain to an executive why I believe this platform should be used... (2 minutes begins now).

Productivity - WPF is a unified platform for UI development. Currently, two of the most used UI development infrastructures (ASP.NET and Windows Forms) provide two very different development experiences. If you need a browser-based application, one skillset is needed and if you need a Windows Forms application, another type of skillset is needed. With WPF, acquired UI development skills can be leveraged across varying application types.

Usability - It's been said that "a picture is worth a thousand words" and the built-in animation and media capabilities of WPF provide the opportunity for assisting both learning and experienced application users. Animations can be used to create illustrations that more effectively communicate items such as sales and marketing trends. In addition, the built-in support for a variety of audio and video types can be leveraged to easily distribute "how-to" videos within an application. This is a massive value add that can drastically improve an application's help documentation. If users are frustrated by an application, they are more likely to find an alternative.

Another one of the great features of WPF is the utilization of vector based graphics. Vector based graphics can address the needs of an aging audience that may have less than perfect eyesight, by providing the opportunity for fonts and certain images to scale in size.

Branding - WPF also helps in creating applications that really match the identity of an organization. Take a look at a corporate logo, generally it uses either a non-web friendly font, incorporates curves/rounded edges, and/or a gradient. While all of this stuff can be done on Windows Forms and Web applications, they can be somewhat difficult to accomplish and often times require compromises. With WPF, shapes and gradients are part of the platform! In addition, by utilizing vector graphics, this branding is scalable.

In addition, WPF provides an excellent opportuntiy to get designers involved in the process by incorporating a model/view architecture. By incorporating designers, UIs can be more relevant, more engaging, and more distinct. (thanks goes to Rei Miyasaka for mentioning this in the comments).

Distribution - WPF also provides the opportunity to distribute an application to a wide variety of user end points. For instance, WPF can be used for desktop applications, intranet/internet applications and Windows Media Center applications.

(end 2 minutes).

After two minutes, only the surface has been scratched. However, before ending this post, I want to mention a facet of productivity that I feel is often overlooked, the availability of community. The .NET community is large and growing. Between the user groups, the forums, and the blogs, I believe that the availability of assistance when needed is one thing that makes the this platform standout over others.

Another thing that I feel often gets overlooked is the fact that there is innovation within integration. Often times integration alleviates ambiguity. This alleviation is a massive value-add that is very hard to calculate. However, I feel that the WPF platform really hits on this concept of innovation through integration. There are other platforms that can do similar things. Some of these platforms can do certain things better. However, I believe if you take into account the entire picture, that is where I feel true value of WPF lies.

I look forward to the comments on this post!