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.



Comments

  • There are no comments yet. Be the first to comment!

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • With JRebel, developers get to see their code changes immediately, fine-tune their code with incremental changes, debug, explore and deploy their code with ease (both locally and remotely), and ultimately spend more time coding instead of waiting for the dreaded application redeploy to finish. Every time a developer tests a code change it takes minutes to build and deploy the application. JRebel keeps the app server running at all times, so testing is instantaneous and interactive.

  • Instead of only managing projects organizations do need to manage value! "Doing the right things" and "doing things right" are the essential ingredients for successful software and systems delivery. Unfortunately, with distributed delivery spanning multiple disciplines, geographies and time zones, many organizations struggle with teams working in silos, broken lines of communication, lack of collaboration, inadequate traceability, and poor project visibility. This often results in organizations "doing the …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds