WSH - Accessing DHTML elements from outside

I'm trying to create a script that will wait till Internet Explorer starts. Then it will access its windows and be able to, lets say, get rid of certain pictures that I don't want.
Using WMI, I think I can get the handle of a new process. I don't know if that will help me. Furthermore, if I have the hWnd of an IE window can I access the HTML inside it somehow using the Shell.Application?

Let me just say that this is an awesome question although complicated in nature. Luckily, the Windows Guru has a solution just for you.

Let's approach this in two parts:

1. The script should wait until Internet Explorer starts.
2. Then it should grab the instance of Internet Explorer and provide access to its Document Object Model (DOM).

Creating an event-driven WMI script to watch for a new process:

WMI provides a little known facet that allows you to write event-driven scripts that react to the occurrence of a specified event rather than executing linearly as soon as the script is launched. Let's look at how to watch for the creation of an instance of the Iexplore.exe process which indicates that Internet Explorer has been launched.

To begin, you'll need to have a basic understanding of how events work in WMI. Your script will create an event consumer. This is basically a listener that waits for notification that a specific event has occurred. WMI will trigger event notifications for a few basic event types. This is beyond the scope of this post so I will only refer to the specific event we'll be using. For more information on WMI event scripting, please read my article series here on ASP Free that explains this in more detail.

Event Scripting with WMI

More Event Scripting with WMI

WMI has an intrinsic event called __InstanceCreationEvent that is triggered whenever a new instance is added to the WMI namespace. As you may well know, WMI's Win32_Process class houses instances of currently running processes. So each time a new process is launched, a new instance of the Win32_Process class is added to WMI's namespace resulting in an __InstanceCreationEvent trigger. By monitoring this event, a script can be notified any time a specific process is started.Your script will start off in a familiar fashion by connecting to an instance of the WMI Service. VBScript's GetObject connects using the winmgmts: moniker, the WMI Service returns an SWbemServices Object. This is the object that allows you to interact with the Windows Management Instrumentation Service on your computer. Traditionally, we would then use the ExecQuery method to return some kind of data collection from WMI. However, this is where our script takes a little turn. We're not interesting in polling WMI for data; we're looking to monitor its events through an event consumer. To do that we'll need to use the SWbemServices Object's ExecNotificationQuery method instead.The ExecNotificationQuery method returns an SWbemEventSource Object which acts as an event consumer. This object acts like a collection that is updated with each new instance of the event we're monitoring. It provides a NextEvent method that will wait for an event to occur and then return an instance of that event as an SWbemObject. In short is means that it returns the class instance that we're monitoring. In this case, it will return the Win32_Process class instance for the newly created process. It should be understood that it doesn't return this instance directly. Rather, it points to it. The SWbemObject has a TargetInstance property that references the instance we're looking for. So where we would normally have a Win32_Process object, we'll now have that object by means of the TargetInstance property.Because this event consumer will continually listen for new events, the WMI script will run indefinitely (or until the WMI Service is stopped). So to continually grab new instances of the event as they occur, we'll wrap our code in an infinite loop using the Do While True syntax. (In this example code, I've explicitly added Exit Do to end the script after the first event is handled. You'll likely want to remove this from your own application.)

In the sample code above, I've demonstrated how you can use this WMI event script. Run the code and then open Internet Explorer. As soon as the program starts, WMI fires the event and the script begins to work displaying a message box with some information about the target process. As you can see, you can retrieve the Hwnd (window handle) for the new instance of Internet Explorer as per your question. You probably won't need it though as you'll soon see.

Okay, let's put this script to work now. You're going to remove everything inside of the Do loop above and place any functioning code you need in its place. Let's address the second part of your question and then I'll show you how you can put the two together.

Capturing instances of Internet Explorer:

Ordinarily you would capture a running process using VBScript's GetObject method. However, it's a bit restrictive in that it doesn't allow you to specify between multiple instances of the same application. In fact, it will usually result in an error if you try. Luckily, the Shell Automation Object provides us with an alternative. It's Windows method returns a ShellWindows Object that represents a collection of Explorer Shell windows. Due to Internet Explorer's close integration with the Explorer Shell, instances of Internet Explorer are also treated as Shell Windows. Each object in the ShellWindows Object collection is an Internet Explorer Object whose Document property gets an instance of the active document's automation object. Nicely enough, this is functionally equivalent to the Document object you would access from a script within the browser.

WMI triggers an event as soon as the process is created. This doesn't imply that the program is running or even functional yet. It's very important that you monitor the Internet Explorer Object's Busy property and do not attempt to access the object before it is fully initialized.This example demonstrates the complete code for accessing the currently running instance of Internet Explorer and waiting for it to initialize completely. It then waits for navigation to complete and displays a message box containing the active document's title.

Notice that I've enclose the latter portion of the script in an If statement that checks that the Document object exists. This is a precautionary measure that will prevent your scripts from breaking under certain circumstances. The Document property WILL NOT return an object if Internet Explorer's script securities are set too high!

Now that you've seen both parts of this script, let's see what the whole thing would look like together.

Thank you very much. Actually being that there was no response for a long time, I looked all over the place and came up with pretty much that. In fact I used the .ExecNotificationQueryAsync and _OnObjectReady that you had once told me about.
I actually needed to recall my script through the run(cscript...) because I wanted to monitor IE for the _DocumentComplete event and I read that you cannot use Wscript.ConnectObject for IE if it wasn't loaded with the page. So I started a new script and created IE from fresh and copied the Top, Left, Height, Width, FullScreen, and of course documentUrl from the old IE into the new one.
One thing still needs clarafication however: In case I wanted to double check that the window I'm dealing with is the same as the process just begun, I would want to check TargetInstance.Handle to match IE.HWND. The thing is that actually no property returned by WMI matches the IE.HWND. What is going on?

That's correct. The _DocumentComplete event is a DOM event and is not exposed by IE's COM interface.I haven't seen the code you're using to clarify, but if you use the code I've shown above, they do match. I tested it.

How are you guys running this code?

I tried it in both a .VBS file and a .WSF file and I kept getting the following error message:


I am running IE6 on Windows 2000 with .NET 2.0.

The code was tested on Windows XP. It's possible that it may not be fully supported on Windows 2000 although I wasn't able to find that in the documentation. See if some error handling can get you around that portion of the code.