Active Script Debugging Overview
The Active Script Debugging interfaces allow language-neutral, host-neutral debugging, and support a wide variety of development environments.
A host-neutral debugger can be automatically used with any Active Scripting host, such as Internet Explorer or a custom host. The host controls what the debugger presents to the user, from the structure of the document tree to the contents and syntax coloring of the debug documents. This allows the debugged source code to be shown in the context of the host document. For example, Internet Explorer can show a script in an HTML page.
In the subsections below, each key component in Active Debugging and its associated interfaces are discussed. However, before proceeding further, several key Active Debugging concepts must be defined:
The application that hosts the script engines and provides a scriptable set of objects (or "object model").
A component that provides parsing, execution, and debugging abstractions for a particular language.
The application that provides debugging UI by communicating with the host application and language engines.
machine debug manager A component that maintains a registry of debuggable application processes.
process debug manager
A component that maintains the tree of debuggable documents for a particular application, tracks the running threads, and so on.
A document context is an abstraction representing a specific range in the source code of a host document.
A code context represents a particular location in the running code of a language engine (a "virtual instruction pointer".)
A particular context (for example, a stack frame) in which expressions may be evaluated by a language engine.
A structured, language-independent representation of an object's name, type, value, and sub-objects, suitable for implementing a "watch window" UI.
Below is an overview of each of the key Active Debugging components and corresponding, associated interfaces, followed by the details of those interfaces.
The language engine provides:
Language parsing and execution.
Debugging support (breakpoints and so on).
Stack enumeration and parsing.
Below are the interfaces that a script engine needs to support to provide debugging, expression evaluation, and object browsing. These interfaces are used by the host application to map between its document context and the engine's code contexts, and also by the debugger UI to do expression evaluation, stack enumeration, and object browsing.
Provides syntax coloring and code context enumeration.
Returns document contexts and stack frames for errors.
Host provided link from script engine to debugger.
Provides a virtual "instruction pointer" in a thread.
Enumerates the code contexts that correspond to a document context.
Represents a logical stack frame on the thread stack.
Provides context in which expressions can be evaluated.
Provides a way to enumerate logical stack frames.
Represents an asynchronously evaluated expression.
Allows a script engine to abstract an operation that needs to be performed while nested in a particular blocked thread.
Provides asynchronous access to a synchronous debug operation.
Provides status events related to progress of an
Enumerates a collection of
Provides a way to enumerate expression contexts known by a certain component.
Allows a language or IDE to customize the conversion between VARIANT values or VARTYPE types and strings.
Enumerates the logical stack frames for the PDM.
Hosts the language engines.
Provides an object model (set of objects that can be scripted).
Defines a tree of documents that can be debugged and their contents.
Organizes scripts into virtual applications.
There are two kinds of hosts:
A dumb host supports just the basic Active Scripting interfaces. It has no control over document structure or organizations; this is determined entirely by the scripts provided to the language engines.
A smart host supports a larger set of interfaces that allows it to define the document tree, document contents, and syntax coloring. There is a set of helper interfaces, described in the next subsection, which make it much easier for a host to be a smart host.
Smart-host Helper Interfaces
IDebugDocumentHelper methods provide a greatly simplified set of interfaces that a host can use to gain the benefits of smart-hosting without handling the full complexity (and power) of the full host interfaces.
A host is not required to use these interfaces, of course. However using these interfaces can avoid implementing or using a number of more complicated interfaces.
Implemented by PDM and provides implementations for many interfaces necessary for smart hosting.
Implemented (optionally) by the host to expose host-specific functionality, such as syntax coloring, to the debugger.
For more information, see Implementing Smart Host Helper Interfaces.
Full Smart-host Interfaces
Below is the full set of interfaces that a smart-host must implement or use if it is not using the helper interfaces.
Interfaces implemented by host:
Provides information on a document, which may or may not be instantiated.
Provides the means for instantiating a document on demand.
The base interface for all debug documents.
Provides access to a text-only version of the debug document.
Allows editing of the text-only version of the debug document.
Provides an abstract representation of a portion of the document being debugged.
Interfaces implemented by PDM on behalf of the host:
Extends the functionality of the
IDebugDocumentProvider interface by providing a context within a project tree.
The IDE is a language-independent debugging UI. It provides:
Expression evaluation and watch windows.
Stack frame browsing.
Browsing the virtual application structure.
Interfaces implemented by the debugger:
The primary interface exposed by a debugger IDE session.
Gives an external component more control over the user interface (UI) of the debugger.
Provides status events for
Provides events indicating changes to the associated text document.
Provides the event interface for the
Machine Debug Manager
The machine debug manager provides the hookup point between virtual applications and debuggers by maintaining and enumerating a list of active virtual applications.
Establishes a debug session for a running application.
The primary interface to the machine debug manager.
Similar to the
IMachineDebugManager interface, but this interface supports debug cookies.
Signals changes in the running application list maintained by the machine debug manager.
Enumerates the running applications on a machine.
Process Debug Manager
The PDM does the following:
Synchronizes the debugging of multiple language engines.
Maintains a tree of debuggable documents.
Merges stack frames.
Coordinates breakpoints and stepping across language engines.
Maintains a debugger thread for asynchronous processing.
Communicates with the machine debug manager and the debugger IDE.
Following are the interfaces provided by the process debug manager.
Primary interface to the process debug manager. This interface can create, add, or remove a virtual application from a process.
Represents a running application.
Exposes non-remotable debugging methods for use by language engines and hosts.
Represents a thread of execution within a particular application.
Allows language engines and hosts to provide thread synchronization and to maintain thread-specific, debug-state information.
Enumerates the running threads in an application.
Dispatches marshaled calls.
Maintains a position for a document in the hierarchy.
Enumerates child nodes of a node associated with an application.
Enumerates the stack frames corresponding to a thread, merged from the engines.
Allows the debug cookie to be set in script debuggers.
Serves as a factory for object browsers and simple connection points for script engines.
Provides a simple way for describing and enumerating the events fired on a particular connection point, for script engines.
Send feedback about: