After getting the basic page analysis working, I wanted to use the information I was gathering, so the next step was to get the hot-key commands working.

In Firefox I’m able to set up command key-bindings in the XUL files of my add-on, and call back into the extensions Javascript. Internet Explorer doesn’t have this pre-packaged support for adding key commands, so instead I have to catch the system key events, detect the combinations I’m interested and call the right functions manually.

There are different ways to do this, depending on what you need. Sven describes how to capture all key events in IE from a BHO, even if the focus is on the address bar. Looking at that made my head hurt, it needs some thread-local variables and mapping to remember which thread is associated with which document.

Luckily, I realized that my needs were a bit simpler. I’m happy to have my commands only work when the focus is on the document itself, which meant I could use the DOM event handlers exposed through IHTMLDocument2 to capture key events.

Attaching a C++ callback to an event handler in the MS DOM is not trivial, and involves some COM boilerplate, but I had a helper class I use to capture onclick events for elements. I’ll cover that along with the rest of my DOM helper functions in a future post.

Reusing that, getting called when a key event occurred was quite easy, though one wrinkle I hit was that onkeypress doesn’t get called for all keys, such as those produced when control is held down. I worked around this by synthesizing an equivalent using onkeydown/up, since they do get called for all keys.

One odd thing about these handlers in IE is that they don’t get passed the event information directly as a parameter. Instead you have to ask the current window what the last event was, and pull the information from that. To get the current window, you have to ask the document, and to get the document, I had to query the browser, since that’s all I store in my class, so the code is a bit verbose. It does the job thought, even if it is uglier than I’d like.

The next hurdle was working out the key codes for the events I was interested in. Here’s what I found for the unusual keys I needed:

• Left Arrow = 37
• Up Arrow = 38
• Right Arrow = 39
• Down Arrow = 40
• Control+Equals= 187
• Control+Forward Slash = 191

I then added a giant switch statement to handle all the key combinations I was interested in, and call the right functions. Once that was wired up, I also implemented saving the enabled state of the add-on in the registry, so users can turn it off when they’re not using it, and it will still be off when they restart IE.

More posts on porting Firefox add-ons to IE

Sven Groot, whose IE BHO development tips I mentioned earlier, has another great post on using the IXMLHTTPRequest object asynchronously in C++. He explains exactly how to use that object’s callback from C++, with a code example. This was the problem that forced me to write my own implementation, since the official documentation had no explanation of how to do this. The other examples I could find had the bits I was interested in mixed with a lot of other functionality, and I didn’t have the knowledge to disentangle them.

I’d highly recommend taking a serious look at Sven’s example if you’re looking for a way to do XMLHttpRequest’s in C++, it really helped me understand what was going on!

More posts on porting Firefox add-ons to IE

PeteSearch relies on Document Object Model (DOM) access to analyze and update HTML pages. This is built-in to Firefox’s Javascript, but in IE you have to use the IHTMLDocument(2/3) COM object. I’ll give some code examples in a later article, but first I want to cover a serious problem I ran into, and the solution I found.   

I was seeing a lot of crashes once I started analyzing search results, and fetching pages. I discovered that the crashes all seemed to happen when multiple threads were all accessing the same document. I was passing a pointer to the IHTMLDocument3 object to the XMLHttpRequest worker threads, and after a little thought, it made sense that this object wasn’t thread-safe, and so I’d need to synchronize my access to it somehow.

This part really puzzled me. I couldn’t figure out a good way to call back my BHO on the main thread, because the BHO doesn’t control the message loop for the main thread, that’s all in IE. And since IE could be using the same object, and I don’t control that code, I couldn’t implement my own manual locking.

Luckily, I came across a life-saving post from Tony Schreiner. He explains that COM objects in IE are not thread-safe by default, but that you can get a wrapped version that adds thread-safe locking by calling CoMarshalInterface(). This gives you a version of the object that you can use on a different thread, without worrying about crashes caused by other threads accessing it at the same time.

It was only a few lines of code, and implementing it removed all the bugs I was hitting. Thanks Tony!

More posts on porting Firefox add-ons to IE

My decision to use WinInet to implement my XMLHttpRequest class turned out to be a mistake! I went back to the drawing-board, and reimplemented the class using WinHttp, the more modern alternative from Microsoft. Here’s the code, the CPeteHttpRequest class that implements the classic XMLHttpRequest interface together with an app to test its use. It’s available for reuse with no restrictions.

Here’s the differences between this new version and the old WinInet-based one:

• It no longer crashes when under heavy multi-thread use
• The interface is now entirely in wide character strings
• WinHttp is only available on Windows 2000, XP and Vista, so use the WinInet code for legacy support

More posts on porting Firefox add-ons to IE