Model-View separation is not a novel idea in the software industry. It has been around for at least 30 years. Recently, however, MV separation is seeing a lot of renewed interest, powered both by the growing complexity of software and by the need to provide different UI experiences, reusing the same underlying business logic.
WPF provides a lot of native functionality (commanding, databinding, etc.), enabling developers to build applications with proper model-view separation. So far, however, we have not provided simple guidance on how to utilize these features to build properly factored applications with model-view separation.
***
I am very happy to announce that on Friday we released the first preliminary version of the WPF Model-View-ViewModel Toolkit (MVVM is WPF’s equivalent of the classic MVC design pattern). The toolkit is available for download on the “WPF Futures” codeplex site.
The toolkit consists of:
- A Visual Studio template, allowing you to quickly create WPF Model-View-ViewModel Applications
- Documentation
- A general introduction to the MVVM design pattern
- A detailed walk-through, demonstrating how to create a simple MVVM application, starting from the skeleton generated by the template
- A complete MVVM application example – a WPF messenger application.
Big kudos to Patrick Danino – an engineer on our team – who worked on the toolkit from inception to its successful first preliminary release.
***
This first preliminary version of the toolkit is fairly simple and clearly not aimed at MVVM experts. We have adopted an evolutionary approach of delivery, so we invite everybody out there – from folks looking to pick up MVVM for their next project to MVVM experts – to collaborate with us on the toolkit, by sharing both real-world experiences as well as first-time-exposure feedback.
We will use this feedback to drive improvements in the toolkit, in the WPF platform and in the relevant authoring tools (Visual Studio, Expression Blend, etc).
I am happy to announce that we have released CTP 5 of the “WPF Application Quality Guide” – our single-stop document for WPF application and component developers and testers.
CTP 5 comes with the following new and updated content:
- New content:
- “Considerations for WPF Browser Applications”
- “Integration and Scenario Testing”
- “XAML Editing Tools and Visual Studio Add-ins”
- “Building a WPF Application Test Suite by Using VSTS, NUnit, or xUnit”
- Updated content:
- Reading roadmap
- “Performance and Scalability Testing”
- “TestApi”
- “Debugging Tools”
- “Performance Profiling Tools”
- “WPF Application Design and Development Tools”
The Guide is available here and here as a DOC file. Big kudos to Anne Gao on our team, who has been PM-ing all releases of the guide to date.
***
Those of you who have been following the Guide have seen it evolve from its first CTP (link) of 20 or so pages to its present size of more than 80 pages.
Any 80-page document is tricky to grok, so we have been thinking of reorganizing the content and potentially splitting the content into two documents – one on client application development and testing fundamentals and one on WPF specifics. We prefer to do any edits based on user feedback, so please let us know of the current organization and content of the document and share your ideas on how we could improve both.
I am excited to announce that we have just released the second preliminary version of TestApi – the testing API library – on http://codeplex.com/testapi!
The v.0.2 package includes the following additions and modifications:
- Improved command-line parsing APIs
- Improved visual verification APIs
- A new tolerance map visual verifier in SnapshotToleranceMapVerifier
- New operations on snapshot (And and Or) allowing you to mask
- A new Snapshot.FromWindow(...) constructor with ability to include and exclude the window chrome in snapshots.
- Improved visual verification internals
- New application control APIs, enabling in-proc and out-of-proc automation of client applications
- Expanded conceptual documentation
- CHM API documents (in addition to the HTML documents)
- Addition of NUnit and xUnit usage samples (for all of the non-VS crowd out there)
Check out the package and let us know of any feedback.
Visual Verification (VV) is the act of verifying that your application or component is displayed correctly on screen. The TestApi library provides a set of VV APIs. This post discusses these APIs.
Avoid It If You Can
First and foremost, I want to emphasize that visual verification is a test technique that should be used with caution. It is difficult to do correctly and any extensive use typically results in hard-to-maintain test codebases. Here are a few things to consider before you embark on VV test development:
- The UI of an application tends to change a lot during development. If you use visual verification extensively, you may end up in a situation where you have to update a large number of visual verification tests on a daily basis, which is a waste of effort.
- There are small differences in rendering between different video cards on different versions of the OS and of .NET. These differences are particularly pronounced in font rendering.
- Before employing any form of UI verification, one should always review the underlying application architecture. Extensive need for UI testing is typically indicative of poorly architected systems, lacking proper view-model separation, so it’s almost always better to invest in proper system architecture than in extensive UI testing.
- Whenever possible, attempt to do analytical visual verification i.e. one that does not employ the use of master images.
The WPF test team has gone through several iterations of cleaning up and retiring unnecessary visual verification tests in an attempt to speed up and stabilize our test suite.
General Concepts
The core VV terminology is:
- Snapshot: A pixel buffer used for representing and evaluating screen image data.
- Verifier: An oracle object which determines whether a snapshot passes against specified inputs.
- Actual: The snapshot being evaluated.
- Master: The reference data (image) which is used to evaluate the actual snapshot.
- Tolerance: The accepted bounding range based on which the actual snapshot will be accepted as valid.
The general VV workflow is:
- Capture some screen content.
- Generate an expected snapshot (e.g. load a master image from disk, etc.)
- Compare the actual snapshot to the expected snapshot and generate the difference (diff) snapshot.
- Verify the diff using a verifier.
- Report test result.
TestApi Visual Verification Technology
TestApi provides the following VV technology:
- Snapshot: this class represents image pixels in a two-dimensional array for use in VV. Every element in the array represents a pixel in a given [row, column] of the image. A Snapshot object can be instantiated from a file (Snapshot.FromFile), or captured from screen (Snapshot.FromWindow and Snapshot.FromRectangle). Snapshot also exposes image cropping (Snapshot.Crop), resizing, diff-ing (Snapshot.CompareTo) masking (Snapshot.And) and merging operations (Snapshot.Or) operations.
- Verifiers: the library provides a set of verifiers that can be used to verify a (diff) snapshot. SnapshotColorVerifier reports passing if
- Various utilities: example of these are the Histogram class, providing basic functionality for handling image histograms
Examples
SnapshotColorVerifier
With these prolegomena out of the way, let’s look at some code. The first example below demonstrates master visual verification using a basic color verifier, which ensures that the difference between the master snapshot and the actual snapshot is within a defined tolerance:
// 1. Capture the actual pixels from a given window
Snapshot actual = Snapshot.FromRectangle(new Rectangle(0, 0, 100, 100));
// 2. Load the reference/master data from a previously saved file
Snapshot expected = Snapshot.FromFile("Expected.png"));
// 3. Compare the actual image with the master image
// This operation creates a difference image. Any regions which are identical in
// the actual and master images appear as black. Areas with significant
// differences are shown in other colors.
Snapshot difference = actual.CompareTo(expected);
// 4. Configure the snapshot verifier - It expects a black image with zero tolerances
SnapshotVerifier v = new SnapshotColorVerifier(Color.Black, new ColorDifference());
// 5. Evaluate the difference image
if (v.Verify(difference) == VerificationResult.Fail)
{
// Log failure, and save the diff file for investigation
actual.ToFile("Actual.png", ImageFormat.Png);
difference.ToFile("Difference.png", ImageFormat.Png);
}
This approach works fine if you are evaluating the correctness of an application logo or some other application art. You may find that you will need to increase the tolerance a bit to accommodate differences in GPU rendering, but in general the SnapshotColorVerifier provides all the functionality you need.
SnapshotHistogramVerifier
A somewhat more sophisticated approach involves using of image histograms (see this link for a good introduction to the subject). An image histogram is a histogram that represents the frequency of pixels with a certain brightness. One can define a histogram that represents his/her expectation of the “proximity of the match” between the actual and expected snapshots.
For example, one can define a histogram semantically equivalent to the following statement:
“When I compare the actual snapshot to the expected snapshot (both of 320 pixels), I expect no more than 30 pixels with color channel difference of 1, no more than 10 pixels with color channel difference of 2, and zero pixels with higher differences.”
This histogram would look as follows:
Figure 1 Image Histogram
Such form of verification is done by using the SnapshotHistogramVerifier and the Histogram classes, as demonstrated in the sample below.
// Take a snapshot, compare to the master image and generate a diff
Snapshot actual = Snapshot.FromRectangle(new Rectangle(0, 0, 100, 100));
Snapshot expected = Snapshot.FromFile("Expected.png"));
Snapshot difference = actual.CompareTo(expected);
// Load the quality histogram from disk and use it to verify the diff
SnapshotVerifier v = new SnapshotHistogramVerifier(Histogram.FromFile("ToleranceHistogram.xml"));
if (v.Verify(difference) == VerificationResult.Fail)
{
// Log failure, and save the actual and diff images for investigation
actual.ToFile("Actual.png", ImageFormat.Png);
difference.ToFile("Difference.png", ImageFormat.Png);
}
The histogram file is just a XML file with the following schema:
<histogram>
<tolerance>
<point x="0" y="0.87500" />
<point x="1" y="0.09375" />
<point x="2" y="0.03125" />
<point x="3" y="0" />
<point x="4" y="0" />
...
<point x="254" y="0" />
<point x="255" y="0" />
</tolerance>
</histogram>
This visual verification approach was pioneered in the WPF test organization about 6 years ago by Marc Cauchy and Pierre-Jean Reissman.
SnapshotToleranceMapVerifier
However, none of the two approaches above work particularly well for evaluation of a typical application window, containing controls, text, etc. Such windows tend to have regions that need different tolerance settings. For example, consider the application window below:
Figure 2 Sample Application Window
If you try to perform master based visual verification, you will hit 2 issues:
- The non-client area of the window (the window frame) will tend to be slightly different between different runs of the application. It will also depend on environment factors such as the desktop wall-paper.
- Some regions of the client area of the window will also tend to exhibit significant variance between runs of the application.
Issue (1) is easy to resolve, using Snapshot.FromWindow(...) and excluding the non-client area from the capture. Issue (2), however, is a bit more involved. Here are the expected, actual and diff snapshots of the client-area of the application.
Figure 3a Expected Client-Area Snapshot
Figure 3b Actual Client-Area Snapshot
Figure 3c Difference Snapshot
Figure 3d Difference Snapshot – Completely Black Pixels Are Replaced With Pink
The differences between the expected snapshot and the actual snapshot are difficult to see on Figure 3c, so on Figure 3d I have replaced purely black pixels with pink.
It is not surprising that most of the variation occurs around the text regions in the application window (ClearType renders differently on different machines). So it may make sense to increase the tolerance (or completely mask away) those regions, providing of course we are not specifically interested in their rendering.
In order to achieve that, we use the SnapshotToleranceMapVerifier class. Here’s an example:
// Take a snapshot, compare to the master image and generate a diff
Snapshot actual = Snapshot.FromWindow(hwndOfYourWindow, );
Snapshot expected = Snapshot.FromFile("Expected.png"));
Snapshot difference = actual.CompareTo(expected);
// Load the tolerance map. Then use it to verify the difference snapshot
Snapshot toleranceMap = Snapshot.FromFile("ExpectedImageToleranceMap.png");
SnapshotVerifier v = new SnapshotToleranceMapVerifier(toleranceMap);
if (v.Verify(difference) == VerificationResult.Fail)
{
// Log failure, and save the actual and diff images for investigation
actual.ToFile("Actual.png", ImageFormat.Png);
difference.ToFile("Difference.png", ImageFormat.Png);
}
The tolerance map that we use looks as follows:
Figure 4 Tolerance Map in “ExpectedImageToleranceMap.png”
What appears pure black (0x00FFFFFF) is actually an off-black color (0x000A0A0A) to handle the small variations that appear as black dots on Figure 3d. Then we also have 4 regions with significantly higher tolerance to handle the variability of the text rendering.
In Conclusion
The visual verification API in TestApi provides a solid foundation for visual verification tests. As a general best practice, however, avoid visual verification as much as possible.
I am pleased to announce that our team just released PhotoSuru - a complete sample application demonstrating how to use the Syndicated Client Experiences Starter Kit for photo-viewing scenarios.
Big kudos to Kevin Gjerstad (our GPM) and the many other folks on the team who worked on this fantastic WPF application.
Check out photoSuru here and here. It will blow your mind :)
I am happy to announce that we have just released the fourth preliminary version of the “WPF Application Quality Guide” with the following new sections:
From here, we will be heading to releasing v1 in the first quarter of 2009. As always, your feedback is greatly appreciated.
The guide is available here. You can also download it as a Word document.
Command-line parsers remind me of linked lists in C++: everybody has written several at various points in their careers. While everybody should write each of those at least once, I doubt that many people out there are particularly excited about writing and re-writing fundamental data structures on a regular basis – it gets old very quickly. Not to mention that doing so is error-prone and decreases the maintainability of a world that’s already hard to maintain.
That’s why modern-day frameworks such as .NET provide standard implementations of the common data structures. And that’s why TestApi provides a reusable command-line parsing APIs via the CommandLineDictionary and CommandLineParser classes, the latter being a type-safe layer on top of the former. Obviously, these are not test APIs per se – they are general utility APIs that happen to be more often used when writing tests.
A few quick examples follow.
Simple Command-Line Parsing
As seen from the first example below, extracting command-line parameters that are primitives is easy. Primitive command-line parameters are either boolean (e.g. the “verbose” flag below), or a key-value pair, that one can extract with the indexer of the CommandLineDictionary instance (see the “testId” key below), just as one would expect from a Dictionary.
//
// EXAMPLE #1: Parsing a command-line such as "RunTests.exe /verbose /testId=123"
//
using System;
using Microsoft.Test;
public class Program
{
public static void Main(string[] args)
{
CommandLineDictionary d = new CommandLineDictionary(args);
bool verbose = d.ContainsKey("verbose");
int testId = Int32.Parse(d["testId"]);
// use the parsed command-line parameters
}
}
By default flags/keys are indicated with the forward slash (“/”) character and values are indicated with the equals character (“=”), but the user can override that upon initialization of of the CommandLineDictionary object:
//
// EXAMPLE #1b: Parsing a command-line such as "RunTests.exe –verbose –testId:123"
//
...
CommandLineDictionary d = new CommandLineDictionary(args, '-', ':');
...
Finally, you one can use the ToString method to get a string representation of the command-line arguments.
Command-Line Argument Structures
Another common pattern when dealing with command-line arguments is populating a structure which contains all parsed arguments. The CommandLineParser class makes this easy:
// EXAMPLE #2:
// Sample for parsing the following command-line:
// Test.exe /verbose /runId=10
// This sample declares a class in which the strongly typed arguments are populated
public class CommandLineArguments
{
bool? Verbose { get; set; }
int? RunId { get; set; }
}
CommandLineArguments a = new CommandLineArguments();
CommandLineParser.ParseArguments(a, args);
Type-Safe Commands
A third common approach is forming strongly-typed commands from the command-line parameters. This is common for cases when the command-line looks as follows:
some-exe COMMAND parameters-to-the-command
The parsing in this case is a little bit more involved:
- Create one class for every supported command, which derives from the Command abstract base class and implements an expected Execute method.
-
Pass an expected command along with the command-line arguments to CommandLineParser.ParseCommand – the method will return a strongly-typed Command instance that can be Execute()-d.
// EXAMPLE #3:
// Sample for parsing the following command-line:
// Test.exe run /runId=10 /verbose
// In this particular case we have an actual command on the command-line (“run”),
// which we want to effectively de-serialize and execute.
public class RunCommand : Command
{
bool? Verbose { get; set; }
int? RunId { get; set; }
public override void Execute()
{
// Implement your "run" execution logic here.
}
}
Command c = new RunCommand();
CommandLineParser.ParseArguments(c, args);
c.Execute();
Besides the parsing logic, CommandLineParser provides a few additional helper methods. One of them is CommandLineParser.PrintCommandUsage, which prints the usage for specific commands (or all supported commands) to the console.
In Conclusion
The command-line parsing APIs released with TestApi provide a simple and “layered” access to the command-line. Strictly speaking these APIs are not test APIs, but have nevertheless been included in TestApi as tests often have a need of parsing parameters on the command-line.
I am starting a series of posts introducing some of the facilities available in TestApi 0.1, a test and utility API library, which we recently released on CodePlex. Most of this content is already available in the documentation provided with the library.
The first post is on input injection – a fairly common activity in UI testing.
General Notes
Input injection is the act of simulating user input. In general, there are several ways to simulate user input, in the following progressively increasing levels of realism:
- Direct method invocation: A test programmatically triggers events by directly calling methods on the target UI element. For example, a test can call the Button.IsPressed method to simulate pressing a WPF button.
- Invocation using an accessibility interface (UIA, MSAA, etc.): A test programmatically triggers events by calling methods on an AutomationElement instance that represents the target UI element.
- Simulation using low-level input: A test simulates input by using low-level input facilities provided by the host operating system. Examples of such facilities on Windows are the SendInput Win32 API and the Raw Input Win32 API, which inject input directly into the OS input stream.
- Simulation using a device driver: A test uses a device driver to simulate input at the device-driver level.
- Simulation using a robot: A test controls a robot to simulate direct human interaction with an input device (for example, pressing keys on a keyboard).
Technique A is framework-specific; what works for WPF does not work for Windows Forms and vice versa. Technique B is less framework-specific than A, but still has limitations, because some frameworks differ in their implementations of the required accessibility interfaces. Techniques C and D are OS-specific. Technique D is significantly more difficult to implement and deploy than C, without a corresponding increase in its level of realism. Technique E is universal, albeit much slower and much more expensive than the other options.
The TestApi library provides facilities both for B (through the AutomationUtilities class) and for C (through the Mouse and Keyboard classes), which are the most generally useful techniques of input simulation.
Examples
The AutomationUtilities class provides wrappers for common UIA operations, such as discovery of UI elements. The first example below demonstrates how to discover and click a WPF Button in a WPF Window, by using the AutomationUtilities class and the Mouse class.
//
// EXAMPLE #1
// This code below discovers and clicks the Close button in an About dialog box, thus
// dismissing the About dialog box.
//
string aboutDialogName = “About”;
string closeButtonName = “Close”;
AutomationElementCollection aboutDialogs = AutomationUtilities.FindElementsByName(
AutomationElement.RootElement,
aboutDialogName);
AutomationElementCollection closeButtons = AutomationUtilities.FindElementsByName(
aboutDialogs[0],
closeButtonName);
//
// You can either invoke the discovered control, through its invoke pattern...
//
InvokePattern p =
closeButtons[0].GetCurrentPattern(InvokePattern.Pattern) as InvokePattern;
p.Invoke();
//
// ... or you can handle the Mouse directly and click on the control.
//
Mouse.MoveTo(closeButton.GetClickablePoint());
Mouse.Click();
The second example below demonstrates how to discover a TextBox instance and type in it, using the Mouse and Keyboard classes as wrappers of common mouse and keyboard operations:
//
// EXAMPLE #2
// Discover the location of a TextBox with a given name.
//
string textboxName = “ssnInputField”;
AutomationElement textBox = AutomationUtilities.FindElementsByName(
AutomationElement.RootElement,
textboxName)[0];
Point textboxLocation = textbox.GetClickablePoint();
//
// Move the mouse to the textbox, click, then type something
//
Mouse.MoveTo(textboxLocation);
Mouse.Click();
Keyboard.Type(“Hello world. ”);
Keyboard.Press(Key.Shift);
Keyboard.Type(“hello, capitalized world.”);
Keyboard.Release(Key.Shift);
In Conclusion
The Mouse and Keyboard classes in the TestApi library can be used for automating of any application, running on Windows. The classes are completely policy- and context-free – their usage is not dependent on a specific test framework or on a specific test workflow. TestApi provides full source code and XML documentation for these classes, so you can either integrate them in your own projects or reference the pre-built DLLs.
Note that, even though Mouse, Keyboard and AutomationUtilities make the life of the test automation developer quite a bit easier, UI testing is tricky and should be avoided whenever possible. It’s always preferable to design your application as a multi-tier application, with a “thin” UI layer, so that you can bypass the UI in most of your tests.
On Friday, we released the first preliminary version of an experimental library with test APIs, named ... TestApi :). With this library, we are sharing internal Microsoft testing technology with the developer and tester community.
We wanted to keep the first release small and contained, so that it can be easily grasped and critiqued, but complete enough to provide actual user value and to clearly demonstrate the direction of this effort.
In addition to the binaries and the source code, we have provided full documentation (both MSDN-style API documents and conceptual documents) as well as a couple of VSTS samples to get you started.
Check out the release on http://codeplex.com/TestApi and let us know what you think.
On Friday, we released the third preliminary version of the "WPF Application Quality Guide", adding a section 3 new sections: a suggested reading roadmap, a section on globalization and localization testing and a section on manual testing and record and replay.
The guide is available here. You can also download it as a Word document.
As always, please send us suggestions both on the content and on the organization of the document. You can post feedback directly here or send it to wpftbest@microsoft.com.
We (the WPF test team) are looking for several engineers, so I wanted to use the blog to point to the available positions in the team and give you a brief outline of the opportunities and responsibilities associated with each position.
Software Development Engineer in Test
(see official job posting)
As a SDET on the team you'll be responsible for ensuring the high quality of the WPF platform, by being the first and most critical customer of the platform, by being the first application developer using the new features introduced in WPF.
An accomplished SDET on our team is...
- a world-class CS engineer;
- an expert application developer, passionate about UI;
- a feature expert, with deep knowledge of specific parts of the WPF stack (e.g. Controls, Application Model, Graphics, etc.);
- fundamentals expert, with deep knowledge of software fundamentals such as security, performance & scalability, globalization/localization, accessibility, etc;
- passionate about code quality, passionate and capable code and design reviewer;
- striving on living on the absolute leading edge (and sometimes bleeding edge :) ) of the WPF technology;
- a capable problem solver and having great sensitivity and zeal for discovering and fixing quality issues in the platform;
- an effective team player.
We are currently looking for both junior and senior SDETs. You don't have to be all of the above in order to apply. You just have to be passionate, smart and willing to learn.
Software Architect
(see official job posting)
We are also looking for several software architects. Software architects are senior individual contributors with broad technical knowledge and experience, who are interested in having broad influence rather than being deep area experts.
A successful software architect on the team is:
- an experienced software engineer with broad knowledge and appreciation of advanced software design and development techniques;
- a passionate "code librarian", driving high code quality, as well as proper architectural layering, componentization and reuse across the organization;
- a fundamentals champion and driver;
- a technical leader and mentor;
- an effective design and code reviewer;
- very friendly and approachable. Willing to be randomized by folks asking for technical guidance and advice.
The Software Architects work closely with the managers and with other senior individual contributors on the team to form a coherent technical vision and strategy, matched with a pragmatic execution plan.
If you think you have what it takes to be successful in one of the best teams at Microsoft and you feel you are ready for a change, drop me a line. We offer working on the most advanced UI platform shipped by Microsoft to date, working alongside some of best and brightest engineering brains in the industry, a supportive and friendly team and practically limitless career growth opportunities.
Today we are releasing the second preliminary version of the "WPF Application Quality Guide", targeted at WPF application and component developers and QA professionals. Check out the document here or download the DOC version here.
This second revision of the document has a lot of new content, so be sure to check it out. We have expanded our section on UI element discovery and have added new sections on general principles of WPF, general principles of software testing, visual verification testing, media testing, animation and transition testing, performance and scalability testing, security testing, data binding and interop. We have also added a section on tools that you can use to develop, debug and test WPF applications and components.
Let us know what you think about the content and the organization of the document. Can you easily find what you are looking for? Are there other topics that you'd like us to include in future revisions? We are looking forward to your feedback, which you can send to wpftbest@microsoft.com or directly to me.
A PC that holds all of your media (music, photos, home videos, movies), allows you to pause, record and play back live TV and looks like a regular consumer electronics device? Sure! It's called a Media Center PC (or Home Theater PC, or HTPC) and I felt it was a high time to assemble one.
The last time I assembled a PC was about 15 years ago as an undergrad student and, boy, those were simpler, purer times. It quickly became apparent that I would spend weeks figuring out what components to use in the PC, given the myriad of motherboards, CPU sockets, etc, etc, etc, so I looked for help on the web, and I came across this great article by Loyd Case.
So I just went ahead and duplicated the cheapest PC configuration recommended by Loyd. Here's what I ended up with:
| Component | Model | Notes | Price |
| Motherboard | Gigabyte GA-MA69GM-S2H | | $86 |
| CPU | AMD Athlon 64 X2 | | $116 |
| CPU Cooler | Scythe Ninja Mini | To replace the original cooler that came with the CPU | $31 |
| Graphics | ATI Radeon X1250 Internal with HDMI | Integrated on the motherboard | n/a |
| Audio | Integrated HD audio | Integrated on the motherboard | n/a |
| Memory | 2GB Kingston ValueRAM (KVR800D2N5K22G) | | $56 |
| Hard Drive | Western Digital WD7500AYYS 750GB | | $201 |
| Optical Drive | Lite-On LH-20A1 DVD Burner | | $36 |
| Case & PSU | Antec Fusion Black 430 | | $150 |
| TV Tuner | ATI TV Wonder HD 650 PCI-express | The package includes a MC remote control.
Note:
There are two problems with this tuner:
a. I couldn't actually get this tuner to receive any over-the-air TV programming, although I tried several different antennas. I have as a result ordered a Hauppauge tuner.
b. The remote that comes with the tuner is a RC5 remote, so it does not work with the integrated RC6 infrared receiver in the Antec box. So I ended up getting another remote (a RC6 one) from a friend, which worked beautifully. See below for pointers to a RC6 remote. | $130 |
| Total | | | $805 |
Putting together the PC took an evening. I installed Windows Vista Ultimate (a smooth uneventful installation, as long as you have a USB keyboard and a USB mouse handy), connected the PC to the Internet, to my TV signal source and to my TV and fired up Windows Media Center. The configuration I ended up with is:
The integrated graphics card on the motherboard conveniently provides HDMI output, so that's what I used to connect the TV to the Media Center PC. You will notice that I have not connected an audio system. I am just using the speakers of my TV (via the same HDMI cable), which frankly are good enough for us.
It took me about 2 days to rip all of my CDs (I used Windows Media Player to do that) and transfer all of my videos and pictures to the PC.
MCE Works Beautifully!
The Windows Media Center included with Windows Vista is an excellent piece of software and works perfectly for me with the above PC config (see the few gotchas I had to deal with). It has it all -- beautiful UI, an excellent set of discoverable features, a natural navigation model. It's just a great example of consumer software. We as a company should advertise it better...
Here are a few screen-shots:
TV Channel Guide
The TV channel guide is updated through Internet. This snapshot shows the channel guide superimposed on top of the currently displayed channel (NBC)
Recorded TV
Shows you representative frames from TV shows you have recorded. Notice that the currently played content is shown in a small PIP pane at the bottom left corner.
Picture Library
Browsing a large number of digital pictures is very easy. We have about 3000 pictures in our library and I have not noticed any degradation in performance or performance issues, when browsing through them. Importing your new pictures is always very easy - you just connect your camera via a USB cable and you get prompted to import the pictures.
Music Library
You can sort by various criteria (album, artists, etc) and you get optimized lists that help you quickly find what you are looking for. Notice how the CD art gets automatically loaded for any recognized album. This feature works very well even for fairly old and/or apocryphal CDs.
A Few Gotchas
Overall, setting up a media center PC has been a breeze. The problems that I hit were:
- Set-up:
- HDMI audio kept getting disabled. To fix this, open up Control Panel > Sound, open up the "Realtek HDMI Output" playback device, disable the device, log off, log on and re-enable the device:
- The integrated IR receiver in the Antec case did not work with remote that came with the TV tuner card. Apparently, the IR receiver is set up to recognize RC6 codes, and my remote was issuing RC5 codes, so I had to use the USB IR receiver that came with the remote (that works just fine -- you just have to be comfortable with the external receiver). Alternatively, get a MS MCE remote (e.g. this one). I approached the Antec support team with questions around this -- they were very responsive.
- The volume knob on the Antec case did not work initially. To fix the problem, I had to download and install the latest version of the iMon utility (from here) and uninstall the VFD utility which came on the CD with the Antec case, and which I had previously installed. iMon is just a souped-up version of VFD.
- The channel guide browsing performance tended to degrade noticeably if I had tuned to a channel before I hit the guide. To fix this, I had to switch to the "High performance" power plan (in Control Panel > Power Options)
- HD channels:
- You cannot get HD channels through you cable provider (see [5] below), so I recommend giving up cable TV (yeah, you'll have to fight your Nip/Tuck addition) and switching to a combination of over-the-Internet NetFlix and a TV antenna.
MCE Hardware Accessories and Software Add-Ins
You may consider getting a few hardware accessories:
| Accessory | Model | Notes | Price |
| Wireless keyboard /mouse | Microsoft Wireless Entertainment Desktop 7000 | A very slick, but somewhat expensive piece. Cheaper alternatives are the ZV1-00004 IR keyboard or the ZV7-00009 IR keyboard, both for $40. | $120 |
| Antenna | TBD | Over-the-air TV broadcasts are free and (in the US) of higher quality than what you can get through a cable TV provider (you can't get HDTV cable content even though you have an HDTV tuner - see [2] below). I have personally disconnected my cable and switched to an antenna (see [5] below). | TBD |
| MCE Remote | Microsoft A9O-00007 WinXP Media Center Infrared Remote Control | As discussed above, if you want to use the IR receiver integrated in the Antec case, you'd need to have a RC6 remote. | $39 |
I also recommend installing the following software (in suggested priority order):
| Software | Notes | Price |
| My NetFlix | MC add-in, which allows you to manage your NetFlix queue and watch streamed NetFlix movies (for as little as $8.99/month - Patrick Danino, one of our test architects, pointed me to this great deal) from within Media Center. Works great! | Free |
| FFDShow Codecs | You may need these codecs to be able to watch video files. | Free |
| ShowGallery hack | You can rip your DVDs to your drive and have MCE display them in a nifty DVD library. Check out this article by Max Zuckerman for a walk-through of how to do it. | Free |
| DVR MS Toolbox | Allows you (among other things) to automatically remove commercials from recorded TV. By the way http://TheGreenButton.com provides a wealth of MCE information (big thanks to Gilman Wong - our dev manager, who is also a big MCE aficionado - for pointing me to it) | Free |
Pearls of MCE Wisdom
Here are a few articles that I'd recommend to any Media Center enthusiast:
[1] Build a Windows Vista Home Theater PC is the excellent article by Loyd Case I used to build our media center PC.
[2] Planning Your Media Center PC: Choosing Your TV Source provides the best description of the different sources of TV signal I have come across.
[3] Review: Antec Fusion Black 430 provides a good review of the Antec PC case.
[4] This post explains how to play CD+G karaoke files in MCE (ok, I admit, I have a few of those lying around...)
[5] All About HDTV Antennas walks you through choosing an HDTV antenna. AntennaWeb.org shows the available over-the-air channels in your ZIP code.
I am happy to announce that we have just released the first preliminary version of the "WPF Application Quality Guide". This document is targeted at WPF application developers and QA professionals.
This document is a first of its kind, so we intend to iterate on it rapidly, modifying the content based on comments from you -- the WPF developer community. In its first preliminary version the document contains a table of (planned) contents as well as a few sections, giving you a taste of what to expect in future revisions.
Check out the document here or download a DOC version of it here. And most importantly -- let us know what you think. Too little detail? Too much detail? Do we have the right sections? Should we add / remove anything from the planned content?
I am delighted to broadcast that earlier today our team released the "Syndicated Client Experiences (SCE) Starter Kit and Reader SDK", affectionately known as "Starter Kit".
The "Starter Kit" is a generalized application skeleton, that allows you as a developer to create reader applications similar to the popular NY Times Reader (#25 in PC World's list of 100 Best Products of 2007). The Kit combines the power of WPF with standardized communication protocols (RSS) to deliver a superior occasionally connected reading experience.
A few existing applications, based on the Starter Kit:
Check it out. The Kit comes with complete source code.
