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

Recently I’ve posted an article at CodeGuru about Implementing Active Script Site
with ATL. In that article I’ve explained basic principles of Active Script hosting
and implementation details using Active Templates Library.
One of the questions I’ve been asked about the article was: “What is Microsoft
Script Control and what is the difference between implementing Active Script Site
interfaces and using the control?”. In this short article I am going to answer
that question by explaining the meaning of Microsoft Script Control and it’s relationship
with Active Script Hosting.

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.

Well, I hope, that this small article can help you make up your mind on using/not using Microsoft Script
Control.


More by Author

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Must Read