Yesterday was an interesting day. I went into the little editor they have for this blog site, and – like I always do – copied the day’s entry out of Word and pasted it into the editor. Everything looked hunky-dory, so I clicked the Submit button, logged out, and went back to work.

 

A little while later, I got a couple of emails telling me that the bottom half of the article was unreadable. That’s nothing new; heck, most of the things I write are unreadable. When I went and looked at the blog, though, it turns out that it really was unreadable: words and sentences were cut in half, margins were out of whack, there was a weird grey box in the middle of the post, etc. All in all, pretty dang weird. I assumed the problem was with some HTML code that I had included in the post, so I tried taking that out and re-posting the article. That didn’t help: even with the HTML removed, I got the same screwy results. I put the HTML back in; same thing. Took the HTML out – well, you guessed it.

 

At that point I decided to try andedit the HTML of the article itself. Holy smokes; what a bad idea that was! Turns out that this blog uses Microsoft Word-like (in other words, crazy) HTML. For example, I would have thought the HTML for the first paragraph of this post would look something like this:

 

{P}Yesterday was an interesting day. I went into the little editor they have for this blog site, and – like I always do – copied the day’s entry out of Word and pasted it into the editor. Everything looked hunky-dory, so I clicked the Submit button, logged out, and went back to work.{/P}

 

Note. To try to avoid problems, I’m using curly braces like these {} rather than traditional HTML tags, at least until I figure out how this all works.

 

Instead, it looks like this:

 

{P class=MsoNormal style="MARGIN: 0in 0in 0pt"}{SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"}Yesterday was an interesting day. I went into the little editor they have for this blog site, and – like I always do – copied the day’s entry out of Word and pasted it into the editor. Everything looked hunky-dory, so I clicked the Submit button, logged out, and went back to work.{/SPAN}{/P}
{P class=MsoNormal style="MARGIN: 0in 0in 0pt"}{SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"}{?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /}{o:p}{/o:p}{/SPAN> {/P}

 

Every individual line in the sample HTML code I posted was surrounded by paragraph tags and span tags and style and font parameters and, well, it was all very … interesting …. And so I tried dutifully to edit each line. I’d make the changes, click the Submit button … and all the weird formatting and weird tags would get added back in, and I’d be left with an unreadable page once more. Eventually I copied the thing out of the blog editor, pasted it into Word, saved the document as a Word file, reset all the formatting, replaced the HTML tags with curly braces, copied the revised article, and pasted it back into the blog editor. That did the trick, but I still don’t know what went wrong, nor do I know why I wasn’t able to fix it. Yet another thing to put on my to-do list, I guess.

 

Of course, I should be used to spending my time figuring out why you can’t do something that seems so simple. Last Friday, for example, I got an email from someone in Microsoft, a guy who actually does our logon scripts (and does some pretty slick things, by the way). He had what sounded like a simple request: he needed to find a way to list:

 

  • Internet Explorer add-ins (the things found in C:\Windows\Downloaded Program Files).
  • Microsoft Outlook add-ins.
  • Windows Explorer add-ins.

He couldn’t figure out how to get at any of these things, and wondered if there was something he was missing. (Actually, what he was missing the first rule of scripting, which is: You can always script anything except what you need to script this very moment.)

 

As it turned out, he was missing a couple things, though I can’t really blame him for not knowing about them. For example, this script will return the items found in C:\Windows\Downloaded Program Files:

 

strComputer = "."

Set objWMIService = GetObject("winmgmts:\\" & strComputer _

    & "\root\cimv2\Applications\MicrosoftIE")

Set colIESettings = objWMIService.ExecQuery _

    ("Select * from MicrosoftIE_Object")

For Each strIESetting in colIESettings

    Wscript.Echo "Code base: " & strIESetting.CodeBase

    Wscript.Echo "Program file: " & strIESetting.ProgramFile

    Wscript.Echo "Status: " & strIESetting.Status

    Wscript.Echo

Next

 

How come he wasn’t aware of this? Well, look at the WMI class being used: root\cimv2\Applications\MicrosoftIE.MicrosoftIE_Object. No one has ever heard of this class before; as near as I can tell it’s never been documented anywhere. In fact, there are a number of classes in the root\cimv2\Applications\MicrosoftIE namespace that might be useful to people. But, again, no one even knows about them. (We do have some sample scripts in the Script Center that use these classes, but they’re buried in some nebulous category like Computer Management, and it’s no wonder no one ever sees them. But that’s an issue we’ll take up some other time.)

 

So how did I know about them? Well, a few months ago, when I was bored, I opened up Wbemtest and just started clicking around, seeing what was in there. Root\cimv2\Applications\MicrosoftIE happened to be one interesting namespace I found. (Note: You might not have this namespace and these classes on your machine. I think they are automatically installed along with IE 5.5, but I could easily be wrong about that.) Another interesting namespace is root\WMI. There are a bunch of classes in this namespace, many of which don’t return any data, but others which do return data. For example, there are a lot of classes that start with MSNdis_80211 which return information about wireless networking. I haven’t had a chance to really dig into these and see how useful they are, but they sure look useful. But, again, undocumented. And not because they’re top-secret and confidential, just because, well, they’ve never been documented.

 

And because I’m running Office 2003, I have a namespace called root\MSApps11. Sure enough, there’s a class in there that lets me get at the Outlook add-ins. (One caveat: this thing won’t return any data unless Outlook is running.) Thus:

 

strComputer = "."

Set objWMIService = GetObject("winmgmts:\\" & strComputer _

    & "\root\MSApps11")

Set colSettings = objWMIService.ExecQuery _

    ("Select * from Win32_OutlookCOMAddin")

For Each strSetting in colSettings

    Wscript.Echo "GUID: " & strSetting.GUID

    Wscript.Echo "Path: " & strSetting.Path

    Wscript.Echo "Name: " & strSetting.Name

    Wscript.Echo "Installed: " & strSetting.Installed

    Wscript.Echo

Next

 

Once more, undocumented, even though there are classes in there for all the Office apps. (Again, one problem with these is that the apps typically have to be running before you can get at the data.) Useful stuff? I can't say for sure. But some of it looks very useful. (Like, say, being able to know what Outlook add-ins people have installed on their computers.)

 

I never did find a way to get at Windows Explorer add-ins, but that doesn’t mean there isn’t one, it just means I haven’t stumbled across it.

 

Obviously this is a problem: there are millions of unwritten scripts lying around simply because people don’t know they can even write those scripts. We get emails all the time from people asking, “How can I know what things I can script on my computer?” or “Can you point me to the one spot where I can find information about all the object models and all the things I can script?” The truth is, we don’t have an answer for them. (Well, unless you consider, “You can’t” or “No” as answers.) This is something we’d love to address in some way, but we haven’t yet come up with anything that seemed reasonable. In the meantime, don’t be afraid to open up Wbemtest and poke around. Likewise, there’s an object browser for scripting called TLViewer that can be useful (though it does have a few quirks). And, of course, the Object Browser in Visual Studio is pretty handy, though buying Visual Studio just to look at a few COM classes might be overkill. I’d be interested in hearing how other people hunt down scriptable items, and any suggestions you might have for ways we can make these items more discoverable to people.

 

As for me, I’ve got HTML fish to fry.