Gus What?!

It has come to my attention that you can’t programmatically close an AIM Module window while it is docked. The window.external.window.close() method does not appear to work in this situation.

For now, the only workaround is to un-dock the window before closing it:

// global aliases as described in a prior post
wnd = window.external.window;
client = window.external.client;
prefs = window.external.prefs;
 
function CloseDockedWindowWorkAround()
{
    // un-dock the window briefly.
    if (client.apiVersion == 1)
       client.docked = false;
    wnd.close();
}

This workaround will be needed in AIM 6.8 through AIM 6.9 Beta 2 (they all return an API version of 1).

I will get this issue fixed in the next AIM 6.9 beta since the plugin window is briefly shown in its undocked state before disappearing.

NOTE: This only applies to the dockable plugin window. All extra windows opened by the plugin can be closed without this workaround since those windows can never be docked.

AIM 6.8 and the AIM 6.9 betas all support AIM Modules. These are HTML and JavaScript based plugins that have full access to the Open AIM API plus client level services like HTTP requests and window management.

One of the nicest aspects of AMO plugins is that you can install and uninstall them without having to sign off. This is fantastic from both a development and user perspective.

I recommend that you get an extra plugin key for developing plugins. Once you publish version 1 and set a finger print (optional) you will not be able to develop your plugin further with that key since only plugins with the registered fingerprint will be allowed to load. The solution to this is to get an extra key that you use for development purposes. Don’t forget to change to the deploy key before publishing.

Here are five tips to help get you started on developing your first plugin:

You can install a plugin by running the .amo file. I typically do “start plugin.amo” from the command line or make file. AIM registers itself as a handler for this file extension. You can install a plugin even while offline.

You should enable the debugging setting in IE for other apps. This helps you attach the JavaScript debugger during development and warns you about unhandled exceptions. With debugging enabled (i.e. not disabled), you can insert “debugger;” statements in your code to trigger the debugger. Go to the Internet Settings control panel and uncheck the highlighted option is to do this.

Create aliases for the window.external.* objects. This makes it easier to use these by assigning them to a variable. I put these at the top of my JavaScript file:

debug=1;
prefs = window.external.prefs;
client= window.external.client;
wnd = window.external.window;
plugin= client.pluginInfo;

Set the AMO_TRACE_ENABLE environment variable to “true” in order to use the window.external.client.trace(msg) function that sends output to the debugger. I do it via the Environment Variables dialog in the System Properties control panel (Windows+Break key, click on Advanced tab, then “Environment Variables” button.)

I also create a trace function that helps me leave trace message that are suppressed when the plugin is deployed. This is a good practice. Note that this code uses the global variables ‘debug’ and ‘client’ that I set up the previous tip. Remember to set debug=0 when you deploy your plugin.

function trace(m)
{
    if (debug)
        client.trace(m);
}

If your plugin fails to install for some reason, make sure your plugin.xml file is well-formed and that the minimum required attributes are there. Here are the minimum. The UUID must be your key with {}’s:

<?xml version="1.0" encoding="utf-8"?>
<plugin 
    schema     = "1"
    type       = "html"
    uuid       = "{00000000-0000-0000-0000-000000000000}"
    name      = "any name you want"
    .
    .
    .
</plugin>

Bonus Tip: See my posts tagged with “tips” for more.