iTunes & iPod Hints & Tips
Progress Bar for VBScript
I decided it would be nice if some of my slower running scripts could show they were still actively working so I had a look around for a way to invoke a progress bar from VBScript. I found a bunch of sample implementations which involve creating and manipulating a small page in Internet Explorer but none seemed to do quite what I wanted so I've created one of my own. The result is a reusable class called ProgBar which looks like this in action:
Rather than a single text zone there are three called Status, Info & Debug. Each can be used to provide different levels of information about the current state of the job in progress. The bar itself can either be filled as a proportion of a fixed number of steps or work as an activity monitor with a small section of "lit" cells travelling from left to right and cycling around as the activity progresses.
Of course nothing is ever quite as easy as it seems. Getting it to work on my old XP box was no trouble but changes in Vista & Windows 7 make it harder to ensure the script has access to the automation object it has just created. I'm still working through the wrinkles of how to detect whether or not the current system settings will allow it to be used or not, and whether to prompt the user to make changes or simply suppress the bar if it cannot work as intended.
Even with XP it turns out there is a slight wrinkle as the current implementation uses a page stored on the local machine and can sometimes trigger the warning illustrated below. Since the code is all in the VBScript and not in the web page the "restriction" blocks nothing at all but simply messes up the layout of the box.
This message can be avoided by opening Internet Explorer > Tools > Internet Options > Advanced tab and checking the option Allow active content to run in files on My Computer.
I found a registry hack that should disable the warning for the duration of the script but it seems to have random success. One script reliably manages to suppress the warning, another with exactly the same section of code can't. GRRR!
I guess in truth it would be easier to recode the scripts in VB.Net and compile them into fully self contained applications, but then they wouldn't be so reusable. As it is the scripts are easy to edit and repurpose for those so inclined.
More details to follow...
... So Windows 8 came out, and it has broken things again. With Windows 7 and Vista turning off the User Account Control feature (UAC) allowed the script to talk to the instance of Internet Explorer that it had created. What I hadn't realised before was that this was due to a side effect of that setting which also disabled a policy flag called EnableLUA. It is Limited User Account (LUA), when enabled, that blocks the communication between the script and the progress bar, but in Windows 8 UAC and LUA are no longer completely tied together. Turning off UAC is a control panel adjustment. Turning off LUA independently of UAC requires diving into the registry. To make things easier I've added another script EnableLUA that reports the current state of the policy setting and allows the user to change it. An unwanted side effect on Windows 8 is that with LUA disabled none of the Metro apps will work. Not sure why they could not have remained working and sandboxed even if the user requires a more relaxed policy for their legacy code, but there it is.