# Saturday, June 27, 2009

I sure do love using the Windows 7 taskbar. (I might have blogged a few times about it already.) I have completely internalized the habit of right-clicking on a running app (or a pinned icon for a non-running one) to open a recent document - whether that app is Word, Notepad, PowerPoint, or whatever. I right-click any Messenger conversation to change my status, and I close instances right from the taskbar preview window. I wish Outlook would give me 5 or 6 jumplist items, like New Message and New Appointment, and I really wish Visual Studio would give me some options too. I am looking forward to new releases that will harness this intuitive way of getting users closer to the files they want to open or the things they want to do.

If you want to put taskbar support into your application, and you're not really a video kind of person, perhaps an MSDN Magazine article will do the trick? Yochay and Sasha should be familiar to my readers - you know these guys know their stuff. The article covers both native and managed development, and concludes with this summary:

In this article, we have explored some features of the Windows 7 taskbar, such as application IDs, thumbnail toolbars, overlay icons, progress bars and jump lists. The Windows 7 taskbar provides a clean, sleek launch surface that strongly benefits users. Integrating into this surface will be a primary goal for any application developer for Windows 7.
Using the native Win32 APIs or the managed Windows API Code Pack provides you with a differentiating opportunity to light up your applications on Windows 7. Bear in mind that the taskbar is the first thing users see after logging on to Windows, and you'll want your application to be pinned to their taskbar.

I completely agree. Give it a read.

Kate

Saturday, June 27, 2009 8:05:20 AM (Eastern Daylight Time, UTC-04:00)  #    
# Thursday, June 25, 2009

The Build a Better App site is all about applications. They've gathered tutorials, videos, and useful libraries for folks who are building client applications. You'll see some old friends of mine on the main page - Code Pack, Tim Huckaby's recent guidance paper, and so on - along with plenty of things I haven't linked to from this blog. But there's more, like profiles of some of the people whose work is on the site (love the fish, Tim) or videos showing the Windows Forms to WPF converter in action, Code Pack demos, and so on. Speaking of videos, Build a Better App has their own channel on YouTube, as well. Jono Wells is twittering on behalf of the site, and blogging too.

If you were at Tech Ed USA, you probably saw the Build a Better App team - they had a colourful presence and fun stickers and clings. There's a slideshow of some of the "better app requests" from attendees and while I doubt anyone will be coding a cloak of invisibility any time soon, there were some pretty cool requests in there.

Take a look around, and if you want to submit some content for the site, let me know and I'll connect you to the right people.

Kate

Thursday, June 25, 2009 7:54:21 AM (Eastern Daylight Time, UTC-04:00)  #    
# Tuesday, June 23, 2009

WPF uses XAML. Silverlight uses XAML. WPF is mostly for writing client (Windows) apps, but XBAPs run in a browser. Silverlight is for the web, but an offline story is planned. It's easy to get confused. Worse, people often feel there is a "vs" aspect to it - Silverlight vs WPF. Mike Taulty puts it like this:

Of course, it's not a fist fight. Mike goes on to elaborate on the continuum of technologies and the way you can share skills between them. He also points to a post by Karl Shifflet that demonstrates how code can be reused between WPF and Silverlight applications.

A vital reference for anyone who is moving around on this continuum is a whitepaper (with companion code) that highlights the similarities and differences between WPF and Silverlight. It's available on Codeplex now. It's full of detailed summaries like this:

Check it out!

Kate

Tuesday, June 23, 2009 5:43:59 PM (Eastern Daylight Time, UTC-04:00)  #    
# Sunday, June 21, 2009

Some simple truths about elevation (as in UAC):

  • A process, once running, cannot elevate itself. You are launched elevated or not.
  • A non elevated process can launch an elevated one. The easiest way is to make a separate exe and embed a manifest, then launch it with ShellExecute.
  • An elevated process, once running, cannot "drop back down" to being elevated. As in the first bullet, you are launched elevated or not.

There are some incredibly complicated ways to launch an elevated process but I don't use them because they are incredibly complicated. But you might have noticed there's a symmetry problem there. Can an elevated process launch a non elevated one? My first answer would be "it doesn't matter, because you shouldn't." My paradigm is that your core app should be non elevated, if at all possible, and if it has one or two admin-ish features, those should be refactored into a separate manifested exe that is launched (from a UI component decorated with the shield), does its stuff and gets out.

However, a case can be made for having some sort of admin app that wants to leverage some other installed application, like Internet Explorer, that could possibly be using a malicious plugin or the like. This admin app would be smart to do its leveraging with a non elevated instance of that application. So how can you do it? Well, according to Aaron Margosis, it's a seven step process in native code. Managed code is left as an exercise for the reader.

If you care, now you know how to do it. And even if you don't care, the symmetry is restored.

Kate

 

Sunday, June 21, 2009 5:30:28 PM (Eastern Daylight Time, UTC-04:00)  #    
# Friday, June 19, 2009

If you already know what NDepend is, all you really need to know is that you can now point CppDepend at some big legacy C++ codebase and start to get your arms around all that code a bit better. If you have vaguely heard about NDepend but weren't really listening because you're a C++ programmer, it's time to change that. You can start by reading an analysis of MFC that uses CppDepend to answer questions like what fraction of member variables have names that start m_ (answer: about half) or what kind of coupling the key classes tend to live with.

Beatiful visualizations and genuine insight. Sure, you're not going to refactor MFC yourself, but imagine pointing all this at your own library!

Kate

Friday, June 19, 2009 2:47:30 PM (Eastern Daylight Time, UTC-04:00)  #    
# Wednesday, June 17, 2009

An interesting article about the "hockey handshake" tradition. One of the first things I needed to understand when I started watching baseball was the handshake thing. 

At the end of a big hockey game, the teams shake hands with each other, that is each player shakes hands with each and every one of the opponents, and generally not with their own teammates at all. I was used to that and I see that as a "ok we were hitting each other, but no hard feelings."

 (from happymooses)

But at the end of a big baseball game, the winning team shakes hands amongst themselves, that is each player shakes hands with roughly half of their team-mates (the ones on the field shake with the ones who were off the field) while the losing team disappears as fast as they can.

 (from smailtronic)

It's tempting to see this as a fundamental Canada/US dichotomy, but it's more a baseball/hockey thing and I suspect it's because hockey is a contact sport and baseball (at least on paper) is not. Forgiving the person who has bruised you and saying "good game" is probably a lot more important in contact sports. And indeed, it seems that football goes for the "shake the opponents hands" tradition.

I have to say I'm more the hockey handshake than the baseball handshake type, even though I'd rather watch baseball than hockey most of the time. I really like the idea of taking the time to reconnect with the opponent and affirm that you're really all part of a large thing (the league and the sport) and are colleagues in that effort. In the same way, everyone in this business is a colleague, even if we compete from time to time.

Kate

 

Wednesday, June 17, 2009 10:25:19 PM (Eastern Daylight Time, UTC-04:00)  #    
# Monday, June 15, 2009

Version 0.9 of the Windows API Code Pack for the Microsoft .NET Framework was released June 11th. This version works with the RC, adds a number of exciting new Windows 7 features, and also incorporates many of the Vista Bridge features as well. (I posted earlier about the different versions of Vista Bridge and Code Pack.) Not only that, but it features VB samples as well as C# ones! You can also see some videos of the functionality in action.

 

You just won't believe how easy Windows 7 development is from managed code using the Code Pack until you give it a try. Expect to see more releases as the year goes on, and keep talking to the team on Code Gallery.

Kate

Monday, June 15, 2009 9:28:09 PM (Eastern Daylight Time, UTC-04:00)  #    
# Saturday, June 13, 2009

Early this spring I delivered several sessions of training for Microsoft. It was for ISVs who wanted to get rolling on Windows 7 as quickly as possible. It's good material that covers a mix of managed and native development to take full advantage of new APIs, new features, and new power in Windows 7. It relies on the Windows API Code Pack and some custom-written wrappers for Windows 7 functionality that isn't in Code Pack at the moment. And now it's available to anyone who wants it.

If you couldn't come to one of the courses I taught, consider this the next-best thing.

Kate

Saturday, June 13, 2009 9:18:13 PM (Eastern Daylight Time, UTC-04:00)  #