Copyright 2008-2009, Paul Jackson, all rights reserved
“SpicIE is a framework which allows you easily to extend Internet Explorer 7/8 with your own plugins. SpicIE wraps/hides the IE COM extension interfaces and makes it easy to develop browser extensions in managed programming languages.”
In my opinion, this is something long overdue. Though I really haven’t had a need to write a browser plugin for anything, my perception – based on the availability of plugins and anecdotal evidence – is that it’s far easier to do in, say, Firefox or most other browsers than it is in Internet Explorer. That being the case, when I saw spicIE today, I decided to download it and see just how much would be involved in writing my first plugin for IE.
First, I downloaded spicIE and installed it. The install gives you a spicIE program group with two sample solutions, a help file and installation/deinstallation instructions:
Plugin.cs is the starting point for your plugin and inherits from SpicIE.Host. The template apparently didn’t like my project name of LoveTheDot.PlugIn.IE and this resulted in some initial build errors:
“In case you're creating a new project from the SpicIE template, either in C# or VB.NET, you should be aware of a naming constraint. The project should not contain any dots or other special characters. Otherwise, there will be a problem with the defined class structure in the codefile of the plugin.”
But these are quickly cleared up and the project then builds cleanly.
The plugin created by the template does have some basic functionality, it ties in to the OnDocumentComplete event and displays a “Hello World!” messagebox:
Building the project and executing the install batch file (which requires it be run as administrator), configures the plugin and now every page that loads within IE will say hello:
So with a little event subscription and a couple lines of code, my plugin can now redirect any arrival at a MSDN URI right back here to my little blog:
Imagine the fun we could have just by changing those URIs to something more interesting and installing this plugin on coworkers’ machines …
Okay, so fun, but not very useful, what else can we do? Really anything we might want to. The spicIE API includes a wealth of possibilities, including access to the page’s Document model. For instance, we could get a list of all the links on a page:
(You’ll probably want to be careful where you run this little sample, or you’ll be clicking OK a lot.)
There’s a bit more involved if you want a user-interface (say a toolbar), but not much.
First create a user control and change it to inherit from SpicIE.Controls.Toolbar and there are two properties that must be overridden:
And some initialization to do in the constructor:
There’s a region in the Plugin.cs class for registering UI controls:
Just insert a line to add the new toolbar to the controls list:
And it becomes available in the browser:
In this case, I gave my toolbar a title and a single button, which I’ll code now just by handling the Clicked event like I would any other button:
The SpicIE.Host class, from which my Plugin descends, has a static method “HostInstance”, which gives access to the browser manipulation methods. So now clicking on the toolbar button navigates the current browser tab to http://www.lovethedot.net.
By allowing us to write Internet Explorer 7/8 browser plugins with managed code, spicIE opens a plugin development to a whole new group of developers.