Well it's not all that difficult.
I've just created something that will enable one to view and edit any scripts that are loaded in the browser.
In essence all you need to do is to create a class library and include a reference to the
DOMHelper dll. Then you just need to create a usercontrol. Design the control as usual and when you come to work on the code element make the class inherit the bho.csseditor.Plugin class.
The first method you'll want to override is the Activate method this will be called when a new document is loaded and when the tab is made visible. The title property will be what's displayed in the tab and there's a property on the base object called ParentFrame from which you can get a reference to the mshtml.WebBrowser and mshtml.Document objects.
Once you are happy about life and your coding, then you can import your shiny new plugin into the DOMHelper. To do this is actually a bit of a nightmare, much harder than I thought it would be, but I'll let you know how I managed it and you can do the same back to me:
I found out using FUSLOGVW that you may need to add the DOMHelper and interop.shdocvw assemblies to the GAC. Having thought about this again you may also be able to get away with placing your assembly in the same folder as the DOMHelper that is loaded by Internet Explorer. You'll have to try this yourself.
Anyway, once you've added the assemblies to the GAC using GACUtil (available as part of the 300Mb SDK) you can then load the assembly. Click the little monitor image and choose add-ins and follow the instructions from there.
There you go - you're up and away.
As a starter for 10 you can
download the DOMScripter Visual Studio Project, which also contains a binary if you're too lazy to build the code yourself.
Any comments would be welcome.
Notes:
- You won't be able to do anything in the designer when the the
class inherits the Plugin class because it's an abstract class, ya de
yada.
- If you have a textbox on your own plugin then you may want to ensure that it receives the attention that it's due i.e. handles backspace correctly by handling the GotFocus() event and calling the ParentFrame.SetFocus().
- You can use the CLR Debugger (also part of the SDK) to run IE and find any bugs.
Usual disclaimers apply.