Scripting

Internal Scripting allows you to write scripts using the Visual Basic or C# programming languages to create functions and procedures to automate things such as creating DataSets, modifying templates, and loading data. In addition to general program functionality, access to the CM4D API is available.

CM4D has no control over what can be done with a script, so it is possible that you could end up writing scripts that lock up, crash, or otherwise disable CM4D. ATS maintains no responsibility for any scripts that you write so exercise caution and be aware of what is being done with your scripts.

Scripting Security

To avoid security issues with macros saved in documents, CM4D scripts are only stored in the Site Database. ATS maintains no responsibility for any scripts that you write so exercise caution and be aware of what is being done with your scripts.

To use scripting, you must have:

• Site Database
• Script User Privileges
• Scripts are controlled by assigning user Privileges in SiteManager. What users can do with scripts, and at what level, is all managed by the Site Database Admin.

Scripting Restrictions

Internal scripting can use many of the API methods, with a few restrictions:

• New documents cannot be created;
• Documents cannot be opened (scripts must act on the active document provided);
• Documents cannot be closed (documents must be closed through the user interface, by the user).

Script Execution

Scripts can be executed in three ways:

Document Open - Document Setup

‘Execute’ Annotation - Annot Properties

On Demand - Execute buttons in Script dialogs

Migrating External Scripts to Internal

Existing external scripts may be migrated into CM4D, but it must be put inside a very specific shell of start/end code and formatted to use internal references (cm4dDoc), rather than external (QaDoc).

Only VB.net or C# are supported, so if you have code in any other language it will need to be migrated accordingly.

Script Configuration

External .NET Assemblies, either global or private, can be called by internal scripts. See the topic, Script Assemblies.

Debugging Scripts

CM4D does not provide a debug environment for scripts. If you are concerned about being able to debug a script before using it in CM4D, you could develop your scripts in Excel or Visual Studio as an external script, and do any debugging in one of those applications. When you are done, migrate the code into CM4D.

If you develop scripts in an external application, you must have a CM4D API license.

See the topic, Create Internal Scripts in Visual Studio.

Microsoft Windows Reference Links (as of June 2014):

.NET Framework Programming in Visual Studio: http://msdn.microsoft.com/en-us/library/k1s94fta(v=vs.90).aspx

.NET Framework Conceptual Overview: http://msdn.microsoft.com/en-us/library/zw4w595w(v=vs.90).aspx

Assemblies in the Common Language Runtime: http://msdn.microsoft.com/en-us/library/hk5f40ct(v=vs.90).aspx

Assembly (CLI): http://en.wikipedia.org/wiki/Assembly_(CLI)

C# Reference: http://msdn.microsoft.com/en-us/library/618ayhy6.aspx

C# Programming Guide: http://msdn.microsoft.com/en-us/library/67ef8sbd.aspx

Visual Basic: http://msdn.microsoft.com/en-us/library/2x7h1hfk.aspx

Visual Basic Programming Guide: http://msdn.microsoft.com/en-us/library/y4wf33f0.aspx

Can we improve this topic?