17 of 26

A while back, I decided that I was going to use C# and Windows Presentation Foundation (WPF) to implement any Windows desktop applications that I write.  I had some exposure to both technologies at my last job and want to learn more of them.  I liked what I saw of the C# language and I think that WPF is a fantastic platform for developing user interfaces.

When coming up to speed on new programming technologies, I really prefer using books to get started rather than searching online.  Books are great for a couple of reasons:

1) A solid chunk of information in one spot rather than having to piece together bits scattered all over the internet. A book is also usually presented in a logical order with the early chapters being basic fundamentals and subsequent chapters building on that.

2) A book has been reviewed and edited so that the information in it is almost always accurate (although sometimes a bit out of date). When you find a random article through Google you really have no idea if the information presented is accurate in any way. And even worse, the information you find is often not dated so you don’t even know if it’s recent.

Google is your best friend when trying to find an answer to a specific question, but it’s really hard to to know what questions to ask when you are unfamiliar with the topic at hand.

I’ve been using the following books to learn C#/WPF:

Professional C# 2005

I got this book a few years ago and it’s decent as an introduction to the C# language. It goes over all of the C# syntax and language features – it’s not bad, but not great either. The major downside is that it only covers version 2.0 of the language (3.0 has been out for a while, and 4.0 is on the way). There is an updated version, Professional C# 2008, which covers C# 3.0.

C# in Depth: What you need to master C# 2 and 3

I’m still working my way through this book, but so far it’s fantastic. The book focuses on detailed explanations of the advanced features that were added in C# 2.0 and 3.0. If you want to really understand of inner workings of the C# language – this book is for you. Due to the advanced topics that it covers, the book assumes that you already know the basics of C#.

WPF in Action with Visual Studio 2008

This book starts off with talking about the history of UI development, covering both Windows drawing and web UI design. It outlines the flaws in these previous approaches to UI development and explains the technical design goals of WPF. It’s interesting background information and I found it helpful to know the motivations behind the design of WPF. The rest of the book covers a set of carefully selected topics in great detail. It’s by no means a comprehensive reference for WPF, but what the book does cover it covers very well. There’s a lot of “how” and “why” explained so that you get a full understanding of each topic. The book is written with a good sense of humor so it’s very easy to read. As of this writing, it’s also the most recent WPF book published and covers .NET 3.5 SP1.

Programming WPF

This book is big (863 pages) and covers a wide range of WPF topics with a good amount of detail. Like WPF In Action, the writing style is excellent and the authors make the material relatively easy to understand. Its topic coverage is a little different than WPF In Action (with some overlap, obviously) so the two books complement each other well.

Since this is my first JavaScript blog post, I need to take a moment to recommend this book:

As far as I’m concerned, this is the JavaScript book to get.  It explains the language at a level of detail that you simply won’t find reading online tutorials and samples.  It covers everything from basic language syntax to AJAX.  It has sections on regular expressions, XML, DOM scripting, and client-side graphics.  It also has great reference sections for the various JavaScript objects: Date, Array, Number, etc.  I am constantly referring to it whenever I’m programming in JavaScript.

Anyway, the purpose of this post is to show a couple of neat things that I discovered about the JavaScript Date object that aren’t readily apparent from most of the samples and tutorials that you’ll find.  w3schools.com has a pretty good Date object reference if you need one.

One thing that you need to keep in mind when dealing with the JavaScript Date object is that the integer value for months is 0 based, not 1 based.  This means that January = 0, February = 1, etc.  For example, the following code:

var today = new Date();  // Creates a date object set to the current date and time
alert( today.toDateString() + "\nMonth integer = " + today.getMonth());

Will show the following message:

What’s really cool about the JavaScript Date object is that it does date math for you.  For example, we could set a date object to be January 1, 2009 and subtract 7 days from it:

var jan1_2009 = new Date(2009, 0, 1);  // Creates a date object set to the January 1, 2009
var oneWeekBefore = new Date(2009, 0, 1 - 7);  // Creates a date object set to the January 1, 2009 minus 7 days

alert("One week before " + jan1_2009.toDateString() + " is " + oneWeekBefore.toDateString());

var oneWeekBefore2 = new Date(2009, 0, 1);  // Creates a date object set to the January 1, 2009
oneWeekBefore2.setDate( oneWeekBefore2.getDate() - 7);  // Subtract 7 days

alert("One week before " + jan1_2009.toDateString() + " is " + oneWeekBefore.toDateString());

Both alerts in the code above would show the following:

You can also use the Date object to figure out how many days are in a given month.  This is particularly useful for determining how many days are in February for a given year.  When you create a Date object with a year, month, and a day of 0 then Date object automatically sets itself to the last day of the previous month.  Remembering that month integers are zero based:

var day = new Date(2009, 2, 0);  // Sets the date to the 0th day in March, which is the last day in February.

alert(day.toDateString() + " : February of 2009 has " + day.getDate() + " days.");

This will display:

The eHow Earnings Tracker stores its data in XML format, so one of the things that I needed to learn how to do was program with XML in Firefox Add-ons.  Mozilla has a whole section of code snippets dedicated to XML but I will walk through exactly what I did in the development of the tracker and point out some gotchas that I figured out along the way.

The first step in this process was to figure out how to create an XML DOM tree in memory.  This turned out to be pretty straightforward to do thanks to Mozilla’s How to create a DOM tree documentation.  I wound up with the following code to create my basic XML DOM hierarchy:

var createEarningsDOM = function()
{
    m_trackerDOM = document.implementation.createDocument(null, null, null);

    var trackerNode = m_trackerDOM.createElement(m_xmlNodeTracker);
    trackerNode.setAttribute(m_xmlAttrVersion, m_xmlVersion);

    m_articleListElem = m_trackerDOM.createElement(m_xmlNodeArticleList);
    trackerNode.appendChild(m_articleListElem);

    m_statsElem = m_trackerDOM.createElement(m_xmlNodeStats);
    trackerNode.appendChild(m_statsElem);

    m_trackerDOM.appendChild(trackerNode);
};

You should notice a couple of things about the source code above.  First, I create variables to hold my node and attribute names.  This ensures consistency when I refer to particular nodes and attributes throughout my code.  It also means that if I decide to change the string for a node or attribute name, I only need to do it in one spot.  The second thing is that I create variables to hold references to DOM nodes so that I can easily manipulate them later in the code.

Now that I was able to create an XML DOM tree in memory, it was time to figure out how to write it out to a file.  Mozilla has some decent documentation on parsing and serializing XML.  I combined the information there with what I learned about file I/O and wrote the following code to serialize my XML DOM to a file:

var s = new XMLSerializer();
XML.prettyIndent = 4;
var xmlString = XML(s.serializeToString(m_trackerDOM)).toXMLString();

if(!FileIO.write(m_earningsFile, xmlString))
{
    throw Error("Failed to save file " + m_earningsFile.path);
}

The “pretty” serialization for XML strings is really cool because it formats the XML so that it’s very readable.  It makes life a lot easier when you need to look at the contents the XML file.

Now that I was able to write out XML to a file, I needed a way to read it back in again later.  I used the DOMParser.  The one thing to watch out for with the DOMParser is that when the parsing fails, it doesn’t throw an exception.  Instead, it returns an XML document that contains the parsing error.

This is the code I came up with for loading the XML DOM from a file:

var fileContents = FileIO.read(currentFile);

if(fileContents)
{
    logMessage("\tParsing file");
    var parser = new DOMParser();
    m_trackerDOM = parser.parseFromString(fileContents, "text/xml");

    logMessage("\tLooking for " + m_xmlNodeArticleList);
    m_articleListElem = m_trackerDOM.getElementsByTagName(m_xmlNodeArticleList)[0];

    if(!m_articleListElem)
    {
        // XML parsing failed, grab error
        var s = new XMLSerializer();
        XML.prettyIndent = 4;
        logMessage(XML(s.serializeToString(m_trackerDOM)).toXMLString());                    
        throw Error("Failed to parse XML data file");
    }
}

In this piece of code, I read in the file contents and parse it, attempting to find the DOM element that I’m looking for.  If I don’t find the element then something has gone wrong – either the parsing failed, or the XML is not what I’m expecting it to be.  In either case, I log the results of the parseFromString() function to my log file so that I know what went wrong.

This is something that I figured out a while back but wanted write about it here since I spent a few hours piecing together the information.

There is an MSDN Walkthrough that gets you most of the way there, but there are a couple of key pieces that I found elsewhere. For example, the walkthrough tells you to place the line [System::STAThreadAttribute] before the _tWinMain() definition but if you’re implementing a standard MFC application then you don’t have _tWinMain() in your source code.

Step 1: Configure the MFC application to compile with CLR support

The best way to achieve interoperability between native C++ and managed .NET code is to compile the application as managed C++ rather than native C++. This is done by going to the Configuration Properties of the project. Under General there is an option “Common Language Runtime support”. Set this to “Common Language Runtime Support /clr”.

Step 2: Add the WPF assemblies to the project

Right-click on the project in the Solution Explorer and choose “References”. Click “Add New Reference”. Under the .NET tab, add WindowsBase, PresentationCore, PresentationFramework, and System. Make sure you Rebuild All after adding any references in order for them to get picked up.

Step 3: Set STAThreadAttribute on the MFC application

WPF requires that STAThreadAttribute be set on the main UI thread. Set this by going to Configuration Properties of the project. Under Linker->Advanced there is an option called “CLR Thread Attribute”. Set this to “STA threading attribute”.

Step 4: Create an instance of HwndSource to wrap the WPF component

System::Windows::Interop::HwndSource is a .NET class that handles the interaction between MFC and .NET components. Create one using the following syntax:

System::Windows::Interop::HwndSourceParameters^ sourceParams = gcnew     System::Windows::Interop::HwndSourceParameters("MyWindowName");
sourceParams->PositionX = x;
sourceParams->PositionY = y;
sourceParams->ParentWindow = System::IntPtr(hWndParent);
sourceParams->WindowStyle = WS_VISIBLE | WS_CHILD;

System::Windows::Interop::HwndSource^ source = gcnew System::Windows::Interop::HwndSource(*sourceParams);
source->SizeToContent = System::Windows::SizeToContent::WidthAndHeight;

Add an HWND member variable to the dialog class and then assign it like this: m_hWnd = (HWND) source->Handle.ToPointer();  The source object and the associated WPF content will remain in existence until you call ::DestroyWindow(m_hWnd).

Step 5: Add the WPF control to the HwndSource wrapper

</strong>System::Windows::Controls::WebBrowser^ browser = gcnew System::Windows::Controls::WebBrowser();

browser->Height = height;
browser->Width = width;
source->RootVisual = browser;<strong>

Step 6: Keep a reference to the WPF object

Since the browser variable will go out of scope after we exit the function doing the creation, we need to somehow hold a reference to it. Managed objects cannot be members of unmanaged objects but you can use a wrapper template called gcroot to get the job done.

Add a member variable to the dialog class:

<span>#include <vcclr.h></span>
<pre><code><span>gcroot</span><span><</span><span>System</span><span>::</span><span>Windows</span><span>::</span><span>Controls</span><span>::</span><span>WebBrowser</span><span>^></span><span> m_webBrowser</span><span>;</span><span> </span></code>

Then add the following line to the code in Step 5:

<code><span>m_webBrowser </span><span>=</span><span> browser</span><span>;</span><span> </span></code>

Now you can access properties and methods on the WPF component through m_webBrowser.

One of the major pieces of the eHow Earnings Tracker involves writing data to an XML file and reading it back later.  Figuring out how to do file I/O in a Firefox add-on was not straightforward due to Mozilla’s wide array of Chrome APIs and spotty documentation.

Unfortunately, file I/O is not one of Mozilla’s new FUEL APIs.  FUEL is a Javascript Library available to Firefox add-ons that is far easier to use than the older XPCOM API.  It was introduced in Firefox 3.0 and Mozilla has been slowly adding functionality to it.

Starting with Mozilla’s file I/O code snippets was a quite confusing – the documentation meanders all over the place showing bits and pieces of code without explaining anything in much depth.  On top of that, they suggest that you use the io.js wrappers at the beginning of the page but then none of the examples shown use it.

Basically what it comes down to is that file I/O is done by using the XPCOM interfaces nsIFile and nsILocalFile.  The io.js wrappers are utility functions used to encapsulate the tedious syntax needed to use them.  I don’t fully understand the purpose of everything in io.js but I will show you what I did figure out and ultimately use in the tracker implementation.

The first thing that I needed to do was get a hold of the current Firefox profile directory since that’s where I wanted to store my data.  I chose the current profile directory because I wanted to be able to support multiple Firefox profiles using the tracker without overwriting each other’s data.

I wound up with the following function to do it:

var getProfileDir = function()
{
    var dir = DirIO.get('ProfD');
    if(!dir || !dir.exists())
    {
        throw Error("Failed to open profile directory");
    }

    return dir;
};

What this code does is create an nsIFile object that represents the profile directory.  ‘ProfD’ is a special string that refers to the profile directory.  You can see a list of the supported strings in the file I/O code snippets.  If you want to open a specific directory path, use DirIO.open() instead of get().

Once you have an nsIFile object, you can do a bunch of things with it.  The following code snippet will try to open a file in the profile directory and create it if it doesn’t already exist:

var openEarningsBackupFile = function(username)
{
    var currentFile = getProfileDir();
    currentFile.append(username + ".xml");

    if(!currentFile.exists())
    {
        if(!FileIO.create(currentFile))
        {
            throw Error("Failed to create earnings backup file");
        }
    }
    return currentFile;
}

The append function of the nsIFile object lets you navigate a file hierarchy one level at a time.  You could go down multiple levels like so:

currentFile.append("path1");
currentFile.append("path2");
currentFile.append("file.xml");

This would navigate to [currentFile.path]\path1\path2\file.xml.  The create() function will create any path segments that don’t already exist.

Keep in mind that the append function modifies the calling object so if you want to open up two different files in a particular directory then the easiest way to do it is to create an nsIFile object that points to the directory and then clone it:

var file1 = getProfileDir();
var file2 = file1.clone();
file1.append("file1.xml");
file2.append("file2.xml");

Once you have an nsIFile object pointed to an existing file you can read from and write to it.  The following copy function shows how to do reads and writes with nsIFile objects using the io.js wrappers:

// srcFile and destFile should be nsIFile objects
var copyFile = function(srcFile, destFile)
{
    var srcText = FileIO.read(srcFile);

    if(!srcText)
    {
        throw Error("Failed to read " + srcFile.path);
    }

    if(!FileIO.write(destFile, srcText))
    {
       throw Error("Failed to copy " + srcFile.path + " to " + destFile.path);
    }
 };

Another not-so-obvious thing to figure out was how to get the path where the add-on is installed.  After quite a bit of searching, I came up with this bit of code:

var getExtensionDir = function()
{
    var dir = Components.classes["@mozilla.org/extensions/manager;1"].getService(Components.interfaces.nsIExtensionManager).getInstallLocation(m_extensionId).getItemLocation(m_extensionId);

    if(!dir)
    {
        throw Error("Failed to get extension installation directory");
    }

    return dir;
};

File I/O in Firefox add-ons is pretty easy to do once you see how all of the pieces fit together.

One of the major challenges with doing software development is that you need to be constantly evaluating the direction that you’re heading in with both the code and the end product.  You can’t just decide to do something and then put your head down and do it.  The landscape changes as you develop a product – you learn better ways to do things, roadblocks come up, and your vision of the end product (and code) becomes more refined and  clear.  If you don’t pay attention to these things as you go along then inevitably you’ll wind up miles away from where you should be in the end.

On the other hand, you can’t be changing direction with the wind either.  This is a trap that many programmers fall into.  If you don’t have a solid starting vision for the product or you constantly change the requirements for the product or how it is implemented then you’ll wind up with a big mess or, even worse, the product will never get finished.

The balancing act of changing things that need to be changed and not changing things too often is one of the things that makes software development as much like an art or craft as an engineering or science.  Complicating things further is the fact that what’s best to do for the product often conflicts with what’s easiest to do in the code.

I was working on the eHow Earnings Tracker last night when I had one of those “aha!” moments where I knew that I needed to change the direction I was heading in.

My original vision for the tracker was that it would automatically detect eHow earnings pages as the user browsed the web.  When an earnings page was detected, the tracker would read the current page of earnings, save them to a file, and compare them to the previous update.  The user would be able to see which articles had increases in earnings from update to update and they would have a history of earnings that could be exported.  This  seemed like it would be fairly straightforward to implement and would be a low friction solution for the user.

As I worked on the code, a number of implementation difficulties arose and it became apparent that there would be some usability issues with the end product.

Implementation difficulties (code):

1. Firefox can have multiple tabs open at once which means that, in theory, multiple earnings pages could be loading at the same time.  Writing code to handle this sort of scenario is very difficult in a Javascript based environment.
2. Due to the fact that the code is only parsing one page of articles at a time and the article order is not guaranteed, the code can’t just blindly read & write the entire contents of the current earnings file stored on disk.  Each time an earnings page is viewed, the file needs to be read in and then its data needs to be compared to the current page of earnings to see whether article entries need to be added or modified.
3. The code would be executing every time an earnings page was viewed, even if it didn’t have to.

Usability issues:

1. The user would have to manually click through each page of articles (which can get tedious since articles are only displayed 10 at a time).
2. Since the code was only seeing one page of articles at a time, it would have no way to inform the users of any articles that were added or removed since the last update.

My “aha!” moment was in realizing that the better way to do this would be give the user an “Update Earnings” button that could be activated whenever they were on their earnings page.  That button will trigger the tool to automatically navigate through all of the users’ earnings pages collecting information.  At the end of the process, an HTML page can be displayed showing a summary of all the earnings data.  This fixes all of the implementation and usability issues in one shot.  It’s a rare case where I can simplify the code and improve the product at the same time.

Since I now have a Firefox plugin that will properly update the browser’s status bar with the URL of the web page being viewed, it’s time to write code that will specifically detect an eHow earnings page.  For those of you following along at home, take the code from the previous post and add the following function just after the updateStatusBar function :

var update = function()
{
    var host = Application.activeWindow.activeTab.uri.host;
    var path = Application.activeWindow.activeTab.uri.path;

    m_eHowMsg = ""

    if(host.search(/www.ehow.com/i) == 0)     
    {         
        // eHow earnings URLs are in the form "http://www.ehow.com/members/user-p#-articles.html" or  "http://www.ehow.com/members/user-articles.html"         
        var userAndPageNumPattern = new RegExp("\/members\/\(.+)-(.+)-articles.html");         
        var userAndPageNumResult = userAndPageNumPattern.exec(path);          
        var userPattern = new RegExp("\/members\/\(.+)-articles.html");         
        var userResult = userPattern.exec(path);          

        if(userAndPageNumResult && (userAndPageNumResult.length < 1))         
        {             
            m_eHowMsg = userAndPageNumResult[1];         
        }
        else if(userResult && (userResult.length &lt; 1))         
        {             
            m_eHowMsg = userResult[1];         
        }     
    }      
    updateStatusBar(m_eHowMsg);
}

This function looks for URLs that match eHow earnings pages and then updates the status bar with the eHow user name that it finds.  To hook this function up, just replace the calls to updateStatusBar in onTabSelect() and onTabLoad() with calls to update().

Now when we navigate to a URL that contains eHow article earnings data we see the username in the status bar (the status bar will be blank for other URLs):

The code from my previous post worked great with a single tab open in Firefox.  However, using multiple tabs exposed a problem – all tabs in a single Firefox window share the same status bar.  Another issue is that the event “DOMContentLoaded” gets fired any time a page finishes loading, regardless of what tab you’re on.  This means that the information in the status bar may or may not actually match the tab that you’re on.

I also found some better techniques for placing my code in a namespace/module that are described here and here.  It’s also worth noting that Mozilla’s Developer Center has documentation for their Javascript APIs and objects.  Unfortunately, the documentation usually isn’t very good and I wind up spending an awful lot of time looking for simple pieces of information.

After a bit of work, I came up with the code below to do what I wanted.  This code only works for Firefox 3.5 because that’s when event data was added for the TabOpen, TabClose, and TabSelect events.  In the code below, event.data is a BrowserTab object.

// Create a global variable for the addon
var g17of26 = {};

g17of26.eHowEarningsTracker = function ()
{
    // Private functions
    var updateStatusBar = function(msg)
    {
        var statusBar = window.document.getElementById("ehow_earnings_tracker_statusbar");

        if(statusBar)
        {
            statusBar.setAttribute("label", msg);
        }
    }

    return {  // This brace must stay on the same line as the return - it's a Javascript quirk

        // This function is called when the browser is first launched
        onBrowserLoad : function()
        {
            Application.activeWindow.events.addListener("TabOpen", g17of26.eHowEarningsTracker.onTabOpen);    
            Application.activeWindow.events.addListener("TabClose", g17of26.eHowEarningsTracker.onTabClose);
            Application.activeWindow.events.addListener("TabSelect", g17of26.eHowEarningsTracker.onTabSelect);

            Application.activeWindow.activeTab.events.addListener("load", g17of26.eHowEarningsTracker.onTabLoad);
        },

        // This function is called when the browser quits
        onBrowserUnload : function()
        {
            window.removeEventListener("load", g17of26.eHowEarningsTracker.browserLoad, false);
            window.removeEventListener("unload", g17of26.eHowEarningsTracker.browserUnload, false);        

            Application.activeWindow.events.removeListener("TabOpen", g17of26.eHowEarningsTracker.onTabOpen);
            Application.activeWindow.events.removeListener("TabClose", g17of26.eHowEarningsTracker.onTabClose);
            Application.activeWindow.events.removeListener("TabSelect", g17of26.eHowEarningsTracker.onTabSelect);
        },

        // This function is called when a tab is opened
        onTabOpen : function(event)
        {
            event.data.events.addListener("load", g17of26.eHowEarningsTracker.onTabLoad);
        },

        // This function is called when a tab is closed
        onTabClose : function(event)
        {
            event.data.events.removeListener("load", g17of26.eHowEarningsTracker.onTabLoad);
        },

        // This function is called when a tab is selected
        onTabSelect : function(event)
        {
            updateStatusBar(Application.activeWindow.activeTab.uri.spec);
        },

        // This function is called when a page finishes loading in a tab
        onTabLoad : function(event)
        {
            if(event.data.uri.spec == Application.activeWindow.activeTab.uri.spec)
            {
                updateStatusBar(event.data.uri.spec);
            }
        }
    };
}(); // the parens here cause the anonymous function to execute and return

// Hook up events
window.addEventListener("load", g17of26.eHowEarningsTracker.onBrowserLoad, false);
window.addEventListener("unload", g17of26.eHowEarningsTracker.onBrowserUnload, false);

As it turns out, hooking up Javascript to XUL so that an addon can actually do something is remarkably similar to linking HTML and Javascript together when doing web development.  The first step is to create a Javascript file and include it it in the XUL file much like you would include a Javascript file in an HTML file:

<overlay id="ehow_earnings_tracker_overlay" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
    <script type="application/x-javascript" src="chrome://ehow_earnings_tracker/content/browser_overlay.js" />
    <statusbar id="status-bar">
        <statusbarpanel id="ehow_earnings_tracker_statusbar" label="" />
    </statusbar>
</overlay>

Now we can add code in browser_overlay.js to actually do something.  In this case, we will update the status bar text with the URL of HTML page that was loaded:

// Creates a global variable called "ehow_earnings_tracker"
var ehow_earnings_tracker =
{
    init:
        function()
        {
            // Grab the contents of the browser
            var appcontent = document.getElementById("appcontent");
            if(appcontent)
            {
                // Get notified when the page is done loading
                appcontent.addEventListener("DOMContentLoaded", ehow_earnings_tracker.onPageLoad, true);
            }
        },

    onPageLoad:
        function(aEvent)
        {
            var doc = aEvent.originalTarget; // doc is document that triggered "onload" event
            var statusBar = document.getElementById("ehow_earnings_tracker_statusbar");

            if(!statusBar)
            {
                return;
            }

            statusBar.setAttribute("label", doc.location.href);
        }
};

// Hook into the window load event
window.addEventListener("load", ehow_earnings_tracker.init, false)

Now, when I run Firefox with my plugin enabled it dynamically updates the status bar with the URL of the loaded page:

Firefox addons are implemented using a combination of XUL, Mozilla’s proprietary XML based language, and Javascript.  For anyone who’s done development with HTML and Javascript, learning to write a Firefox addon is pretty straightforward.  All you need is a decent tutorial to get started.  Fortunately, finding tutorials on how to create addons for Firefox is pretty easy.  Some of the ones I found were pretty old, but as far as I could tell the information was still accurate. If you need to learn Javascript, there are plenty of tutorials over on W3Schools.  If you prefer books, I highly recommend David Flanagan’s Javascript: The Definitive Guide.

I decided to start with a tutorial from Mozilla which shows you how to create a classic “Hello World” program by displaying “Hello, World” in the browser’s status bar.   I went through the tutorial quickly and easily by following the exact steps that were outlined in the tutorial.  “Hello, World” showed up my the status bar without  a hitch.  The flaw with this tutorial is that it doesn’t show you how to make the addon actually do something, which is the topic of my next post.

Another useful article I found was this article on Lifehacker that gives some good tips for getting set up to develop Firefox addons.