WinFX

I’ve created a PowerShell CmdLet to show pipeline data in a WPF based Grid. WPFGridSnapIn.zip
To install:
1. Unzip the archive
2. Open a VS 2005 or VS Orcas Beta 1 command line (to get the right installutil version)
3. CD to the “WPFGridCommand\WPFGridCommand\bin\Debug” directory under wherever you unziped to.
4. InstallUtil WPFCommandCommand.dll
5. Start powershell
6. add-pssnapin WpfOutSnapIn
7. ps | out-wpfgrid

Step 7 should show you a grid of processes if it all works.

Implementing this was not straigtforward. I ended up using a separate process to host the WPF application and using WCF to communicate with it. Hosting WPF inside a PowerShell process ended up being a problem because there can only be one WPF Application object in a domain. I was able to work around that by initially reusing an existing Application, but any other WPF based CmdLet would be forced to use my Application derived object. Hosting out of process even though it’s slower, solved that issue and allows the grid to survive Powershell being shut down.

Microsoft’s “On-Demand Webcasts” are a great resource. Microsoft archives their live webcasts and makes them available for free via MSDN. I encourage everyone to have a look around.

1. Advanced .NET Programming for Grid Computing Dan Ciruli from DigiPede reviews grid computing, largely in the context of their product.
2. Windows Presentation Foundation Properties, Events, and Commands - covers Dependency Properties, Events, Commands
3. Amazing but True: Things You Never Dreamed You Could Do with Windows PowerShell - quite strange really, and the rendition of the Notre Dame fight song made me puke (Go Blue!) but if you sit through about 5 minutes of goofiness you learn some cool Powershell stuff.
4. Client-Centric Programming Using the “Atlas” Client Script Library - Digs into the Atlas Client Script Library, covering some of the lesser-known corners and advanced techniques in Atlas. Cool!
5. Java Interoperability with .NET

Plus two bonus webcasts - Top 10 Tips for Word 2007 and Top 10 Tips for Excel 2007. I don’t know about you, but I find that Office 2007 is a major departure from the earlier versions and I am still getting up to speed. As with most of the links above, the first 5 minutes or so tends to be a bit fluffy but then it provides some great red meat.

This video from Microsoft’s Channel 9 shows a very cool hack used to interact with 2D controls in 3D. This fills a major hole in V1 of WPF 3D support. Source code is provided.

‘Control.InvokeRequired’ is one of the mostly used functions in developing muti-threaded GUIs in .NET Framework. While developing a sample application for Vista, I wanted to use the same functionality but new WPF controls living in System.Windows.Controls namespace don’t have ‘InvokeRequired’ (similarly don’t have Invoke and BeginInvoke methods as WPF Controls do not implement ISynchronizeInvoke interface) Read the rest of this entry »

Suprisingly, the New York Times has developed a rich client reader application using WPF and .NET 3.0. I learned about it here.

Seems a bit tough on their core Apple using constituency

I want to put together a Wednesday night talk, but I’ve dabbled in so much technology recently that I’m having trouble deciding on a topic. Here are the topics I’m thinking about so please let me know which ones you prefer:

Windows Presentation Foundation Fundamentals - How to get started with WPF
Windows Communication Foundation - Why is it better/different than ASP.Net, WSE, Remoting, etc?
Linq and C# 3.0 - MS finally brings OO persistence support to the table
Databinding in Windows Presentation Foundation - How to get your data onto the screen in an easy way

WPF is Microsoft’s new API for graphics and user interface work. Its object-oriented all the way down, is architected to efficiently work across remote desktop, and is to a certain extent hardware accelerated.

To the developer, the API appears as a “scene graph” or strongly typed DOM tree called the “Visual Tree”, and changing what is displayed on screen is effected by making changes to the “Visual Tree”.

Theres really two parts to this API, one of which is hidden from the user. Manipulations to the “Visual Tree” are asynchronously sent across to the hidden API as deltas. Presumably, the hidden API maintains a copy of the “Visual Tree”, which it then uses for rendering. The advantage of this approach is in enabling remote-desktop capabilities. The “Visual Tree” can exists on one machine, while the rendering of that tree can happen on another computer, the deltas being sent across the net.

When writing high-performance code for WPF, its important to recognise that this asynchronous communications channel exists, and comes with a price. Optimisation now spans not only considerations of what is being displayed, but also the volume of changes being made to the Visual Tree (and therefore the aggregate quantity, size, and complexity of the deltas being sent across to the hidden API).

A prime example of the impact of this architecture is animation. In WPF, a number of animation classes are provided, for example, for animating an object along a path. Using these animation classes is a huge win, because the parameters for the path are fairly compact and need only be sent across to the hidden API once (and there are possibly other rendering optimisations the hidden API can make by knowing the animation path ahead of time). If you attempt to animate an object along a path by sending it new coordinates N times per second, performance suffers.

Another example of the impact of this communications channel is that it is often more efficient to make one large change to the visual tree rather than many small changes. In practice, this will entail taking a clone of a subtree, making the required changes, and then swapping this modified subtree into place. This last technique is a very important one to be aware of.

Whilst what I know about this communications channel is limited mostly to educated guesswork, I would say that there is some kind of serialization involved, with the tree deltas being serialized to something like BAML (a Binary-XML-like serialization format) before being sent across the wire. Even when the visual tree and the renderer exist on the same machine, the communications channel still exists and is relatively expensive. It is quite possible to saturate the channel (i.e. go to 100% CPU usage), by trying to push too many deltas through it.

Optimisation for WPF is in some ways a data compression problem. If you can get your data “over to the other side” once, and then send compact control parameters over to manipulate or select that data, you get a net win. For rich-media applications, this stuff isn’t too much of a problem, but for applications with volumes of unanticipated data, such as real-time visualisations, grids of ticking stock data, and so forth, its a bit of a problem.

What would be interesting is if the communications channel was in some way programmable, such that the programmer could push code over the channel “to the other side”, and then push a stream of data to be interpreted by that code.

Again, my understanding of this communications channel comes mostly from seeing the shadows it casts, rather than having dragged the beast out into the harsh light of day and beating the life out of it. If anyone can correct me on anything I have said, or help me understand this better, I would greatly appreciate it.america first creditalmondnet adverse credit remortgage httpprograms accredited nurse anethesiaaccreditation abft costunion abnb creditaccreditation ct acr phantomcredit card processingcom merchant washington accountcredit union alcona alpena Map

Jelle Druyts of Microsoft Belgium introduces the Command Pattern, as implemented in Windows Presentation Foundation:

Windows Presentation Foundation (formerly codenamed “Avalon”), or WPF for short, is a brand new Microsoft framework for developing very rich and powerful Windows applications. It will ship as part of Windows Vista, the next major version of Windows that will be released in the coming months, but WPF will also be available on Windows XP SP2 and Windows Server 2003. There is much to be said about Windows Presentation Foundation and its numerous new and enhanced capabilities, but this article will in stead focus on an old trusted friend, who has finally been given a dedicated room in the big house of Windows User Interface development: the “Command” pattern. This design pattern basically abstracts all actions the user can perform in an application into the notion of “commands”; it has been implemented in many different ways on top of various UI frameworks, but now, it has finally made it into the gut of the system itself. Note that this article is based on a public preview of WPF, so it’s possible that there are implementation details that will change over time as the product matures into completion.

go here for the full text of his article.

Avalon/WinFX promises a new level of quality in text rendering, but what about performance?

This powerpoint document describes the text rendering architecture of avalon.

Until the advent of DirectX 10 hardware, we should’nt expect any performance increases over and above that found in GDI+, which achives approximately 100K glyphs per second using a CPU-intensive process. With DirectX 10 hardware (not currently available), this should improve by a factor of 10, making it comparable to the GDI text rendering with the kind of hardware acceleration found on a VGA card circa 1996.

Plus ca change, plus c’est la meme chose.

For really fast text rendering on DirectX 9 class hardware, you should use a monospaced font, assigning each character in the font to a sprite, and using the 3D rendering hardware to assemble the characters into words and sentences. Conceptually identical to, but somewhat less capable than a Gutenberg printing press, multi-million glyphs per second performance levels should be within reach that way.

At the first Indie Game Jam in 2002, a number of games programmers experimented with using what was modern 3D graphics hardware at the time, trying to come up with games that featured a LOT of simple guys (or dudes). What they found was that you could manage a LOT of guys (or dudes) using that hardware, i.e. a GForce 2 could manage 100K guys (or dudes). My favorite game that came out of that IGJ was called “angry god bowling”.

Interestingly enough, similar techniques are what is called for when trying to maximise text rendering performance. At the same time, you could use the capability of independantly moving each character around for some highly disturbing and entertaining effects. Im thinking along the lines of a barely perceptible wavy motion, or of a particle effect such as each character flying off the screen in different directions. Something to think about on long cold nights, eh?

For some unknown reason, Microsoft has to decided not to release a DataGrid like control with the WPF libraries. This is quite a barrier to getting up and running fast when building a data intensive business application. This was some correspondence that I received from MS on the issue in the microsoft.public.windows.developer.winfx.avalon newsgroup:

Thanks for your feedback, we’ve always thought of data grid as an important control but it’s nice to hear you confirm that thinking. While Microsoft doesn’t plan to write a data grid in the WPF V1 timeframe, we’re working with component vendors to ensure a vibrant set a third party components for WPF, and we expect that data grids will be among the most popular offerings. Infragistics for example announced its DataPresenter for WPF at the PDC (I understand they’re putting together some form of CTP program for their components, might want to contact them if you’re interested). We’ll also keep your feedback in mind when we begin planning future versions of WPF.

Well, gee, thanks. So I went and grabbed the nifty beta version of the Infragistics DataPresenter control. It looks promising in the PDC videos, but currently fails to compile:

Jason,

The WPF controls we have made publicly available are designed to work only against the PDC build of WinFX, and therefore you will see errors if you attempt to use them against the November CTP. We will be releasing updated versions of the controls sometime in the future.

Ok, great. Except that everyone just jumped to the December CTP! Let’s hope for some backward compatibility. While not wanting to wait around, I’m attempting to see what I can get by designing my own custom grid control in XAML by slapping together some layout grids, buttons and text boxes. Forgetting about rendering performance for now, I’m just trying to databind each cell of the grid to a particular cell in the DataTable that I’m binding to using the Binding object in C#:

TextBlock tb = new TextBlock();
Binding b = new Binding("Table.Rows[" + rowCount + "][" + columnCount + "]");
b.Mode = BindingMode.TwoWay;
b.Source = this.DataView;
tb.SetBinding(TextBlock.TextProperty, b);

This assumes that my custom DataGrid control has a Dependency Property “DataView”, therefore I’m binding to the DataView’s Table.Rows collection, using the provided indexer to zero in on the correct column and row. This will unfortunately be unable to ever update the data in the table based on changes in the DataView.

Again from microsoft.public.windows.developer.winfx.avalon:

DataTable doesn’t generate property changes- you change the contents, but nothing notifies the UI that the stuff changed. To get this, you need to make a wrapper for the DataTable that generates the necessary events (INotifyCollectionChanged), or exposes the data as an ObservableCollection.

The ObservableCollection is a super lame conversion, and Avalon has completely ignored the entire System.Data framework. I don’t know what to say, but the two don’t communicate. Sorry.

While following those instructions to make DataView implement INotifyCollectionChanged does work, it mucks up my code more than I like. And doesn’t it defeat the purpose of using databinding if you need to manually fire all changes anyway?

I’ll leave you with with this quote from the O’Reilly Programming Windows Presentation Foundation book:

As of the current build, WPF has no direct support for binding to relational databases, and the indirect support is not in such great shape either

Well, it’s not like anyone would ever want to do something crazy that like anyway, would they?

By now we are all hearing rumblings around Windows Vista, WinFX, WPF (Avalon) and XAML. WinFX is the new approach to designing applications for Windows Vista (formerly codenamed Longhorn), but beta versions of the libraries are already available, consisting of the Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF) and Windows Workflow Foundation (WWF). One of the common threads around the architecture will be that substantial portions will be based on XAML, the Extensible Application Markup Language.

XAML is an extension of XML which allows one to create and initialize .NET objects. There is a very close mapping between XAML markup files and the actual .NET/WPF object definitions and anything that is created in XAML could also be coded in C# as usual. The clear win here is the ability to design a Windows GUI in markup form, completely separating out things such as business logic, persistence (data-binding) and event handling.

From Windows Presentation Foundation” (Chris Sells and Ian Griffiths)

the look is something that you’re likely to want handled by someone with artistic sensibilities (a.k.a “turtleneck-wearing designer types”), whereas the behavior is something you’ll want to leave to the coders (a.k.a
“pocket-protector-wearing engineer types”) Ideally we’d like to move the imperative “look” code into a declarative format suitable for tools to create with some drag ‘n’ drop magic. For WPF, that format is XAML.

Sure, you could come close with a strict MVC design earlier, but it is very easy (at least in the small amount of GUI programming I’ve done, rather than service/persistence development) to end up embedding logic, persistence and routing into your forms.

To give an example of the benefits of XAML, the following C# code to build a simple window:

public class MyWindow : Window {

	public MyWindow()  {
		this.Title = "My WPF Window";

		// add a button
		Button button = new Button();
		button.Content = "The Button Text";
		this.AddChild(button);

	}
}

can also be written in XAML:

<Window x:Class="MyWindow">
    xmlns="http://schemas.microsoft.com/winfx/avalon/2005"
    xmlns:x="http://schemas.microsoft.com/winfx/xaml/2005"
    Title="My WPF Window"
    >
    <Button x:Name=”button”>The Button Text</Button>
</Window>

That obviously barely scratches the tip of the tip of iceberg, but I think you get the idea. Your GUI is laid out in XAML separate from the logic and persistence that you implement in the C# classes backing these forms.

Now I’m all for separation of presentation from behavior and this seems like a large improvement over the Winforms style of relying on your C# code to manage all form widgets (similar to my first C# example). However, it is also possible to set up your databinding and event handling code inside the XAML files. And as I’ve started to work on learning WPF, I’ve noticed a disturbing tendency in various materials and publications to encourage pushing as much as possible into XAML. It’s not uncommon to find statements in assorted blogs and learning materials such as,”Well here’s how you do in C# but why bother doing that when you can just do it in XAML?!!” For the tutorials that I’ve examined so far, this leads to the trivial code examples that have databinding and event handling completely intermingled within the exact same XAML lines describing the graphic layout of your windows and forms. I believe this is rather contradictory as it seems to defeat the primary benefit that XAML is bringing to the WPF world. It’s certainly not something I’d want to give to my designer. We are right back where we started, only everything is XAML now.

It seems to me that as we progress through 2006, the development community will gain more and more experience building larger non-trivial apps with WPF and WinFX. Best practices will come out (maybe they are already there) regarding proper separation of concerns between GUI layout and backing control, event and persistence code. And a lot of this will depend on the implementations of WPF designer tools which are again out in beta (Cider and Sparkle) because in the end, who really wants to handcode all of that XAML? They will be generating the XAML for us and it’ll interesting to see their approaches to that task.

And maybe I’m just grouchy because as one of those “engineer types” (sans pocket-protector), I tend to like my OO code and have a hard time parting with it!

In the Avalon programming model, the framework does a lot of work to implicitly wire up things which would require explicit coding in other (i.e. WinForms) paradigms. Routed Events is a great example of this. It’s quite a paradigm shift but once you get your head around it you’ll see the point.

The key concept is that events (well, “Routed” events) are implicitly passed up / down through the containment hierarchy. The way this works is that first, an analagous “PreviewXXX” event is “Tunnelled” down from the top (root) of the hierarchy to the target object. Then, the “XXX” event is “Bubbled” up from the target object to the root.
Read the rest of this entry »

As promised I have assembled some bookmarks (posted on delicious for all to see); small list for now but will grow.

.net2
winfx
visual studio 2005