Crazy Project
In a fairly extreme showcase of latent creativity and masochism, I have designed the beginnings of a VBScript user interface toolkit. It launches Internet Explorer and allows bidirectional communication with a script in a separate file. Since VBScript has no pure way to use multiple files in a programming project, I am required to place my program code in the same file as the toolkit, which just kind of shows how nutty this type of project really is.
Program code looks something like:
Sub Main(argc, argv)
Dim i
Set i = New ExplorerInterface
i.Title = "Explorer Interface"
i.Visible = True
i.bindEvent "boom", "onclick", "React"
i.Run
End Sub
Sub React(context, trigger)
context.findElement("test").innerHTML = "BANG BANG BANG!"
End Sub
Once you set up the interface, you change the window title and make it visible. Then, bindEvent says, “When the object named ‘boom’ is clicked, run the ‘React’ subroutine.” i.Run starts up the event loop, meaning the program is now waiting for user input. The program cleans up and quits as soon as the browser is closed.
Event handling is carried out via a hidden text box in the web browser’s document. Whenever any bound event happens, it adds a little token to that text box, like ‘boom$onclick’. Then, every 0.1 seconds the application checks the box for any signals and runs the proper event (‘React’ in this case) if that action was recently recorded. React in this example finds a designated paragraph in the browser document and changes its text to “BANG BANG BANG!”
The live nature of this - being able to bind events on the fly between script world and browser world, is accomplished via some truly aborrent JavaScript, which is hot-inserted by the VBScript mid-execution.
Doing things this way gives you a lot of flexibility. Internet Explorer is especially picky about running wacko scripts like this directly, so all this indirection serves to insulate me from various security measures. I am free to instance Excel as well (definitely my plan for this project) and carry out automation tasks while logging progress and errors to the web browser window.
In a more realistic world, events are more like triggers (pressing the “START” button) and then the script takes over, basically ignoring any further input aside from maybe a “PAUSE” button. Anyway, it’s pretty much useful for any scripting application, with the right infrastructure.
I have used IE interfaces in the past for scripting, but I’ve never formalized the setup to be more universally-applicable and easy to use. I’m hoping I can use this in various automation projects.