Viewing Compact Framework Source

Many of us who develop for the Pocket PC have discovered that we can't use tools like Reflector to view to source code for the assemblies Microsoft provides, such as System.Windows.Forms. To see what I mean, try this. Open Reflector and from the File menu, select Open List... This will display the Assembly List Management dialog box, which allows you to create lists of assemblies so you can quickly load the assemblies you want into Reflector.

Next click on the Add button to create a new assembly list. I called my list "Compact Framework 2.0". Click on the Select button and you'll get a list of assemblies you can use to initially populate your new list. I selected .NET Compact Framework 2.0 from the Start 'Compact Framework 2.0' Assembly List dialog box and then clicked on the OK button to add these assemblies to the list.

Now if you open the a class, like ButtonBase in System.Windows.Forms, and display the source, you'll see something like this:

This certainly isn't very useful. Well, my colleague Daniel Cazzulino posted a question about this and got an answer. Now that I think about it, it makes perfect sense that you can't get source from the shipping assemblies. In order to keep the installed size as small as possible, the Compact Framework team removed the reflection information.

However, if you have Visual Studio, it ships with a separate set of assemblies that include all the reflection information. I created a new list in Reflector, but this time I clicked on the Cancel button when it asked me what assemblies I wanted in my list. Then I selected Open from the File and and added the assemblies that were installed here on my computer:

C:\Program Files\Microsoft Visual Studio 8\SmartDevices\SDK\CompactFramework\2.0\v2.0\Debugger\BCL

Now I get the source code, as shown here, for the same exact class:

Very nice! Thanks Daniel!

WYSIWYG Blog Editor

I've a visual guy, so I really like to see what my blog will look like while I'm writing it. I've used some blog editors in the past, but had problems with them. Today I just discovered a really, really nice blog editor, called Windows Live Writer.

What's really cool about this editor is that it works with my Blogger, which is what I use for my blogs. And even better, it pulls down the template that I have on my site and let's me see exactly what my blog entry will look like while I write it. The colors are the same. The borders are the same. Etc. Very cool!

They also have an SDK, so it looks like there is a certain amount of customizing you can perform with plug-ins. I haven't looked at it yet, so I'm not sure what you can do.

New Resource for CAB Developers

I recently started working on a project based on the Composite UI Application Block (CAB) from the patterns & practices group at Microsoft. I was initially lost and found it was difficult to find topics in the help. Like many developers, I don't like to read the manual before I get started, but it seems like the documentation is written more like a book than a help file. As a result, "topics" in the help file actually contain a number of topics and you have to scroll through looking for something that might be relevant. I also discovered that there weren't that many hyperlinks.

I also discovered lots of really useful information spread all over the net, mostly in blogs. But there didn't seem to a be a single, central source to find information.

Then it dawned on me. A Wiki would be a great place to have lots of useful information about CAB. So over a weekend I setup a Wiki to cover CAB and related technologies.

Please check out the site, and more importantly, please add to the site. This is a community site. Anyone can sign in and edit or add content.

www.cabpedia.com

Creating a Splash Screen in a CAB Application

We thought about adding support in mobile CAB (Composite UI Application Block) for showing a splash screen at the very start of the application startup, but didn't get around to adding that support. I've just started working on a desktop application based on CAB, so now I'm actually a user of CAB instead of a "developer" of mobile CAB. As it turns out, it's very easy to add a splash screen.

The information below is based on a CAB application created using the Smart Client Software Factory.

Once you get beyond the most basic of CAB applications, it can take a while to load the application. Most applications have splash screens that appear as early in the process as possible and go away once the main UI appears. Here is a simple way you can do this in your own applications.

Create A new Application Class

First create a new Application generic you'll use to start your application. For example:

public abstract class SmartClientSplashApplication<TWorkItem, TShell, TSplash>
       : SmartClientApplication<TWorkItem, TShell>
   where TWorkItem : WorkItem, new()
   where TShell : Form
   where TSplash : Form, new()
{
   private TSplash _splash;

   public SmartClientSplashApplication()
   {
       _splash = new TSplash();
       _splash.Show();
   }

   protected override void AfterShellCreated()
   {
       base.AfterShellCreated();
       Shell.Activated += new EventHandler(Shell_Activated);
   }

   void Shell_Activated(object sender, EventArgs e)
   {
       Shell.Activated -= new EventHandler(Shell_Activated);
       _splash.Hide();
       _splash.Dispose();
       _splash = null;
   }
}

Create a Splash Screen

The splash screen is a form that has something on it, like a bitmap and perhaps some text, like the version number and a copyright. You can also set the border to None so you don't see the usual window. After all, it's shown while the application is loading, so you can't close it yourself.

Change Program.cs

Finally, modify the startup code in Program.cs, or ShellApplication.cs if it was generated by the Smart Client Software Factory, to use this new generic class:

class ShellApplication : SmartClientSplashApplication<WorkItem, ShellForm, SplashForm>
...      

Microsoft patterns & practices Mobile Client Software Factory

I just spent the last 7 months working as a contractor at Microsoft, in their patterns & practices group. They hired me to help create their Moblile Client Software Factory; this project was very rewarding and a lot of fun. They needed an expert on mobile development, which is where I came into the picture. I always wanted to see what it was like to work at Microsoft, and the fact that I live about 1-1/2 miles (as the crow flies) from Microsoft made the transition easy.

This group uses a number of practices that were new to me. All their projects are developed using Agile practices, which includes some of the following areas that were new to me:

• Test-Driven Development
• Pair Programming
• The entire team is in a team room
• Rapid iterations

There are more points, but that should give you a starting point. As a programmer, I've always worked in a private office so I could focus and not be distracted. The idea of working in a team environment, without a quiet place to work, was different than what I was used to, but hey, it was a contract. If I'd come into a full-time job where I wouldn't have my own office, I think I would have been very reluctant to accept the offer. After all, I really need my quiet to focus and get my job done. Or so I thought...

Fast forward 7 months. I proposed a new project in the patterns & practices group and got it funded, so I'm now working on a new project under contract. I was offered the use of someone else's office, but I chose instead to find space in another team room. What's that you're saying? Why would I chose a noisy team room over a quiet office?

The answer is a little complicated, but it's also something everyone else here has discovered. None of the people here wanted to give up private offices. However, now that they've experienced the agile environment, they don't want to go back to private offices. There are several reasons for this.

First, the dynamic of a team environment really does provide better shared knoweledge of the project. You feal more involved because you are more involved. And you have a better sense of how all the pieces fit together and what other people are working on.

However, more importantly is the dynamic of pair programming. Here you have two people on one computer. We've done it where we have two keyboards and mice on a single computer. One person writes a unit test describing what the code should do, and then the other person writes the minimal amount of code to make that unit test pass. Next you switch roles. This process produces simpler, more reliable code than you get from a single programmer, and it also makes keeping your energy level high during the project easier.