Microsoft Script Control - What is it and who should use it

Script Control - What is it?

I think, that the best explanation of Microsoft Script control is an old tech-support joke. I am sure, that you've already heard it more than once, but I can't think of a better explanation. The joke is about "what would happen if car tech-support would look like computer tech-support".

Unsatisified customers calls Volvo tech support department:
Customer: "Hi, my car isn't working. I enter it, close the door and nothing happens."
Tech-Support Person: "Have you tried the ignition, sir?"
Customer: "Come on! I am not a technical person, I just wanna go places in my car!"

Microsoft Script Control is for programmers who can say "I am not a COM person, I just wanna have scripting in my program!". That's it. Microsoft Script control simplifies the use of Active Scripting Engines by eliminating the need in implementing relatively complex COM interfaces (IActiveScriptSite and IActiveScriptSiteWindow) and supplying easy object-oriented interface to most of Active Scripting functionality.

Script Control - How is it done?

If you want to work with Microsoft Script Control, you'd better understand it's internal functionality (at least on a high level). Microsoft Script Control has an implementation of IActiveScriptSite and IActiveScriptSiteWindow interfaces. It provides wrapping for some of the IActiveScript methods. It also bubbles some of the events recieved via IActiveScriptSite interface to a Script Control host using Error and Timeout events. Access to all Active Scripting features is very simplified. For example: to add a named object to a scripting environment you only need to call ScriptControl.AddObject instead of calling IActiveScript::AddItem and implementing quite a complicated IActiveScriptSite::GetItemInfo. When the Language property of Script Control is set, it calls CoCreateInstance with a matching engine CLSID and "forwards" all information supplied by user to a Scripting Engine.

Script Control - Who should use it?