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?

Well, actually I've already answered this question: Programmers, who aren't interested in "getting their hands dirty" with COM and only want to implement a simple scripting in their application, definitely should use Microsoft Script Control instead of implementing IActiveScriptSite. This approach is recommended for 4GL developers (Visual Basic, PowerBuilder, maybe also Delphi), because it is much more easy. Personally, I don't think that serious C++ developers shouldn't use Microsoft Script Control due to following reasons:

a) In MSVC the difference in complexity between using the control and implementing IActiveScriptSite is much less significant than in 4GL.

b) If Active Scripting is an important part of your application, you might like to connect to Active Scripting language-neutral debugger in the future. I am not sure that this could be done easily with Microsoft Script Control.

c) Microsoft's approach is to implement more and more services as COM objects instead of plain API functions, so if you are a serious Windows developer, you MUST understand and know how to use COM.