Hi! It looks like you're new here. Welcome! If you like what you see, I encourage you to subscribe to my RSS feed. If you're worried about adding another RSS feed that will add to your information overload, don't! I'm not a prolific poster. Thanks for visiting!

The project I’m currently working on is getting really close to being done, with Windows Vista having been “RTM”ed recently. We have a few more days to get last minute bugs ironed out and then it’s “off to the factories”… I can’t say much more about the project right now, but it’s a pretty significant and highly visible piece of software coming out somehwere around February 2007. I hope it does well. But I digress…

At this late a stage in a product’s delivery cycle it is common to make very few changes to the code in order not to create more bugs than one fixes. Ideally each change should be peer-reviewed and thouroughly tested before getting checked in (like with Windows Vista and the contortions people have to go through in the “shiproom” to get a bugfix approved). Too bad for me that I’m the only “peer” on the project (i.e. I’m the only developer). There’s nobody I can go to for a review.

And in the last few weeks I’ve broken the “as few changes as possible” rule a number of times. Why? Because I’m confident in the features that WPF provides. And because I do tend to run extensive tests before I check stuff in.

So what kinds of changes have I put in at the “last minute”? I’ve shuffled buttons around on the page, I’ve added code for drawing the user’s eyes to input fields containing invalid data, I’ve added data-bound and data-driven UI elements.

WPF has given me the confidence to be able to do this at the last minute. The fact that moving buttons around is a simple XAML markup change, for example, is just great for last minute UI adjustments.

But I’m not exactly proud of doing it. Oh well. So far everything seems to have worked out.

Share This

Categories: WPF
No Comments »

Here’s an interesting thing I learned the other day, which wasn’t obvious to me.

If you have an XBAP WPF application that tries to access files at the location identified by CSIDL_COMMON_APPDATA (Environment.SpecialFolders.CommonApplicationData in .Net 2.0/3.0) they need to be marked with Read/Write permissions for ”Everyone”. Otherwise File Virtualization kicks in and Vista creates copies of the files in the VirtualStore.

This shouldn’t be a problem per se, but if you have data integrity issues with your application reading/writing files it’s nice to eliminate the virtualization for troubleshooting.

Also, if your application needs to share the same data among users you don’t want virtualization, since that is a per-user thing, and you’d end up with one set of data files for each user.

If you’re installing some default data files for the application using Windows Installer (which will run elevated), you need to make sure you change the permissions on the data files so “Everyone” gets read/write permissions. This can be done using the LockPermissions table of Windows Installer.

Share This

Categories: WPF
No Comments »

In one of my past posts, I talked a little about my impressions of Vista as a platform for software developers. Here’s the story of how I got involved with WPF.

My last two projects before starting on WPF were built around hosting IE in “something”.

The first “something” was an exe hosting IE and adding a bunch of window.external functionality. I took the lead in moving a somewhat old, pretty static UI infrastructure for presenting internet-updatable content to the XML/CSS/XSLT age. That involved a lot of using dynamic expressions to enable reflowing of the UI for different monitor sizes (the app was a fullscreen app). Towards the end of that project I started hearing about an XML-based application development thing coming from Microsoft, and I remember thinking “How cool! No more need for the mess of HTML / CSS / XSLT and JScript/dynamic expressions to glue it together.”

 The second “something” was an application for Windows Media Center, which at the time only offered hosted IE as its application development model (with a bunch of window.external functionality thrown in to get at the Media Center stuff, similar to how our exe had worked). Three of us wrote a pretty interesting little application that shipped for about a year and then was discontinued when circumstances changed on us drastically. Around the time this happened, the XML-based app development thing from Microsoft, better known then as “Avalon”, took more shape.

I was lucky enough to get to experience the energy that Microsoft projected at PDC05. It felt like an explosion of enthusiasm around the newly re-christened “Windows Presentation Foundation”. My eyes were popping at Greg Schechter’s talk. Manuel Clement’s talk was chock-full infectious excitement. I wanted to work with this new stuff.

Luckily the project(s) we were given to work on next required a level of “polish” that I doubted we could achieve using HTML, WinForms or any other technology we were proficient in. I advocated strongly for using WPF, and for some reason management went along. One of the requirements for one of the projects was that it had to run under Vista and more specifically under Media Center to get a great user experience. The level of “polish” that was required pretty much ruled out using HTML. We could have done all ActiveX controls, I suppose, or an HTML/Flash hybrid, but none of us had the required expertise to implement that, and the time frame was extremely tight to begin with.

To me the only way to solve the problem was using the incredible leverage of WPF to “get things done”, even with the steep, steep initial learning curve. I worked on some throw-away applications just to show my manager that this new platform had incredible potential and that I would be able to pick it up quickly enough to work with it seriously. He liked what he saw. The rest is material for another post. Let me just say now that the devil is in the details, and we had lots of challenges on the project overall. Once it’s out there I can talk more about it, but not yet.

Share This

Categories: WPF
No Comments »

This is a collection of tools that should be in every WPF developer’s toolbelt, if you ask me:

XAMLPad (from the Windows SDK [Full ISO|Express Web Download])
Snoop (from Pete Blois)
Perforator (from the Windows SDK) (Don’t forget to turn on the required debugging setting in the registry - mentioned in the article)
CLR Profiler
.Net Reflector (from Lutz Roeder)

If you’re a designer / developer you also want:

Microsoft Expression: Interactive Designer
MOBIFORM Aurora XAML Designer
Electric Rain Zam3D

And of course the staples:

.Net Framework 3.0 September 2006 CTP (I usually pick the complete installer to avoid download problems - it’s hidden a few paragraphs down under a link that says “for x86″)
Visual Studio 2005 / Visual Studio 2005 Express
“Cider” / “Orcas Preview for WPF”

Did I miss anything?

Share This

Categories: WPF
No Comments »

To me Windows Vista marks a great new milestone for software developers. Not just because Microsoft invested years of development into a new programming framework, but because that framework will be included out of the box. Until now, if you wanted to take advantage of the power of the .Net Framework (1.0, 1.1 and 2.0) you had to either include the installer for the framework or create some other magic to get it on the user’s system (asking the user to please, please download and install it first?)

With Vista, not only do you get the .Net Framework 2.0 (much improved over the previous versions) in the box, but also the amazingly powerful Windows Presentation Foundation (which is what I’ve worked with), Windows Communication Foundation and Windows Workflow Foundation (two pieces I know nothing about yet).

This will lower the barrier to entry for applications developed using these powerful tools to zero. As long as you’re writing your application for Vista you can be sure the basic requirements are there.

There will be issues with certain features of WPF (rendering in software vs. hardware, especially for 3D), but the framework helps you detect these issues and makes it possible to adapt your application to lower its “flashyness” (RenderCapability.Tier, remember this needs to be shifted down by 16 bits if you want to use 0, 1 and 2 as the human readable values).

To me Windows Presentation Foundation is the most important technology to come out of Microsoft for a long time. I’ve never written too much actual Win32 or even MFC/ATL UI code for client applications, but I’ve done a lot of HTML / CSS stuff and pure business object stuff (COM/ATL). More about that in my next post. I don’t want this to get too long.

Share This

Categories: Vista, WPF
1 Comment »

I discovered that

System.Windows.Media.RenderCapability.Tierreported a wrong tier (zero) after I upgraded my Windows XP dev box’s .Net Framework 3.0 installation to the RC1 release. My card used to be a tier two and I had just upgraded the drivers, too. I contacted Microsoft about it and they said this is a known issue with the RC1 release and that it will be fixed in the upcoming RTM release. The problem is only with this particular API and only happens on Windows XP. All the actual rendering is still done correctly based on the capabilities of the hardware. So the only problem is if your WPF application is built to behave differently based on the value of this API call.There is a workaround that has to do with changing the value type of a certain registry entry (the video memory size) from Binary to DWORD. I’ll point to more details once I get a URL from Microsoft to point to.

Share This

Categories: WPF
No Comments »

I ran into an issue where my WPF application would consume about 20% of CPU time just sitting idle on a Page. A question from Tim Sneath led me to investigate an aspect of the app that uses the CompositionTarget.Rendering callback to do some animations that can’t be done in other ways in WPF right now.

I had several UIElements that each had the Rendering event hooked up, and the code in the event handler would do next to nothing most of the time, since the animation only was kicked off on a mouse up event. I modified the code, so that the event hookup doesn’t happen until the mouse up event comes in, and also so that an unhook happens when the animation is finished. This promptly took down the CPU load to the typical intermittent 1-2%.

Share This

Categories: WPF
2 Comments »

I thought I’d make my first post not just a “hello out there”, but something that’s marginally useful to some people. 

If you’re writing a Windows Presentation Foundation app that has just a little bit of complexity to it, you may do things like hook up UI Elements to event handlers. This could be for navigation, reacting to data changes, timers etc.

An important thing to remember is to unhoook those event handlers when your UI Element is unloaded. Otherwise the event handler hangs on to the visual tree and the garbage collector will not let go of it. This results in memory consumption “problems”, which is a nice word for a “managed memory leak”.

So if you do something like this:

public MyElement()
{
  InitializeComponent();
  Loaded += new EventHandler(OnLoaded);
}

public void OnLoaded(object sender, EventArgs e)
{
  myTimer.Tick += new EventHandler(OnTick);
}

Don’t forget to also hook the Unloaded event and do this in it:

public void Unloaded(object sender, EventArgs e)
{
  myTimer.Tick -= new EventHandler(OnTick);
}

Share This

Categories: WPF
1 Comment »