Categories: Tools | Comments [0] | # | Posted on Wednesday, June 3, 2009 6:31:36 PM (GMT Daylight Time, UTC+01:00)   

If you are an application developer on Windows Media Center you've probably experienced some pain with our Details view of the stack trace, mostly because you can't copy + paste nor see the entire stack traces if it is over a certain length. Starting in Windows 7 you can now launch Event Viewer and navigate to the Applications and Services Logs > Media Center node to see these stack traces. For example, the screenshot below is what you would see if you ran the MarkupDebugging.mcml sample within Windows Media Center and pressed the button labeled 'Crash The Application'. Note this is independent of the EnableErrorDetails registry key enabling the 'Details' button on the dialog end users see when an application crashes -- this event will always be written. This log file is one of those gathered with the Media Center Diagnostic Tools I posted about here making it really helpful to communicate your applications crashes to us during the beta.

Categories: Tools | Windows Media Center | Debugging | Comments [0] | # | Posted on Saturday, January 17, 2009 12:44:23 AM (GMT Standard Time, UTC+00:00)   

I'm really, really glad our team did the work to make these publicly available. The Media Center Diagnostic Tool gathers a lot of pertinent information very useful to the team in troubleshooting issues with Windows Media Center. If you ever file a bug report during the beta or are working with someone at Microsoft to determine what's happening it's a good idea to have these tools installed and take a snapshot of your system to share with the person helping you.

Media Center Diagnostic (MCDiag) Tool [x64]

Media Center Diagnostic (MCDiag) Tool [x86]

Categories: Tools | Windows Media Center | Comments [7] | # | Posted on Saturday, January 17, 2009 12:26:58 AM (GMT Standard Time, UTC+00:00)   

If there is one technical oriented blog you should read it has to be Scott Hanselman. This morning I read Be Aware of DPI with Image PNGs in WPF - Images Scale Weird or are Blurry and instantly went 'gee willikers'. Most of the images you use with Media Center Markup Language (MCML) will be in the PNG format if they are part of your <UI> if for no other reason you can embed alpha transparency information within the PNG (which you can't with JPEG or GIF). On a whim I ran the PNG assets we ship with the SDK sampler through PNGOUT and found an average file size savings of just above 50%. This can be a pretty significant size savings for resources in assemblies but can be even more important / significant for web experiences due to bandwidth costs (both in terms of hosting / bandwidth dollars AND perceived responsiveness by the user.

I highly encourage you to click through (and subscribe) to Scotts blog, but if you want the quick tools here is what I used:

PNGOUT (Command Line)

PNGGauntlet (GUI)

Categories: Media Center Markup Language | Tools | Windows Media Center | Comments [2] | # | Posted on Tuesday, January 6, 2009 8:13:53 PM (GMT Standard Time, UTC+00:00)   

Found this earlier tonight -- I've been pondering whether or not creating some MCML snippets would be helpful. This looks like it might really help speed the process and take out a lot of the tedium of hand creating the XML for snippets.

Snipp Dogg is a snippet editor for use with Visual Studio 2005 and 2008 Intellisense Snippets. This tool allows you to create fully functional and robust snippets to streamline the development process and make code reuse a snap.

Get it from

Categories: Tools | Comments [0] | # | Posted on Wednesday, July 23, 2008 8:27:38 AM (GMT Daylight Time, UTC+01:00)   

[This is probably the first of a series of posts...]

I've been falling in love with Windows all over again recently with Windows Vista.

While creating the Diamond SDK we had to edit the file redistribution list heavily because we added a ton of new resources. See C:\Program Files\Microsoft SDKs\Windows Media Center\v5.0\License\redist.txt for this -- it tells you what files we give you permission as a developer to redistribute in some form or fashion with your apps.

To generate this list, I installed a release candidate of the SDK and pulled out one of my rarely used, but favorite tools to enumerate the files and folders exactly as they appear in the file system post-install: FileGrab. When you drop files from Explorer onto the FileGrab window, you get a list of filenames, instead of the files' contents. You can save the list to disk, print it, or copy it to the Clipboard for pasting into another application. View options let you choose which file characteristics (such as date, size, or attributes) to include with the filenames.

FileGrab was created by Michael Mefford at PC Magazine...

...for Windows 95.

I have run it on every version Microsoft has shipped since -- including Windows Vista.

This is one of the hallmark features for which I consistently rank Windows above all other operating systems I've used over the years with each subsequent release (which would include MacOS, Linux, Solaris and BeOS among others): Its ability to run the software I like to use even if it was written light years ago in computing time.

FileGrab has worked great for me the last 10 years. As with any software though, eventually, at some point, it can be improved. While FileGrab has always met the need, each time I leveraged there were always a few improvements I would have made for my personal use. For example...

  1. It has more features than I personally need -- extended file attributes, the ability to print the enumerated list as a couple of examples.
  2. A feature missing which I always yearned for -- the ability to enumerate files or folders or both during a drag and drop operation and denote folders with a trailing slash ('\').
  3. A mildly annoying feature I would call a 'bug' today that, at the time it was created, could certainly have been a limitation of the underlying platform -- a fixed length (number of characters) for the file name which resulted in unecessary white space in the text.

So, while on a recent vacation I finalized a new tool inspired by FileGrab called FileAndPath to address these issues. When you drop files from Windows Explorer onto the FileAndPath window, you get the following at the time of the operation...

  1. A list of file names or folder names or both.
  2. Full path or file / folder name only.
  3. An optional trailing slash ('\') added to folder names.

The options for the generated list are limited to saving to disk or copying to the clipboard.

So, take your pick -- both tools (though written ten years apart) run just fine on Windows Vista.



Categories: Tools | Windows Vista | Comments [5] | # | Posted on Friday, February 16, 2007 7:39:54 AM (GMT Standard Time, UTC+00:00)   
RSS 2.0
Sign In | All Content © 2014 Charlie Owen

This is a personal weblog. The opinions expressed here represent my own and not those of my employer.

Powered by newtelligence dasBlog 2.3.9074.18820