The Reflection application programming interface (API) is built on Microsoft .NET technology, and as a result, takes advantage of its many benefits. This API exposes many functions programmatically, providing a whole range of opportunities for creating rich custom applications. For example, you can integrate Web browser and Productivity features into your host applications.

Where do I start?

The MyReflection object is the starting point of the API and has methods you can use to create Application objects. An Application object represents a single Reflection instance. You can create Application objects for as many Reflection instances as you want to work with. MyReflection also includes methods that you can use to start a Reflection instance (if one isn't already running) and to stop a Reflection instance started by your program. By using the CreateApplication( ) method (of MyReflection) with the appropriate IPC channel name, you can create an Application object for a Reflection instance on the local computer.

In most cases, you'll create one Application object for each Reflection instance. You can keep this Application object instance around and refer to it in your application. After you create an Application object, you can get other objects from the Application that represent major functional areas in Reflection. For example, you can get a Frame object to work with a user interface.

 

Accessing session data

A control represents the data aspect of an opened Reflection document and can take many forms, such as an IbmTerminal or WebControl. By calling the CreateControl( ) method on an Application object, you can create a new session or Web document. Several different CreateControl( ) methods exist for you to use in different scenarios. (Similarly, you can get a control for a document that's already running by using the GetControl( ) method.)

To identify and get controls from existing documents, you can use the instance ID, the name, or the file path of the underlying document. The name property of a control is initially empty. You can leave it blank or set it to the identifier you want. However, the name property does not persist after you close the session document.

The following diagrams show objects that can be accessed from the control.

Interacting with UI elements

 Two high level objects are required to display Reflectionsessions:  

• The Frame object is the high level user interface control for the Reflection workspace that controls how the workspace is displayed. It also is a container for the View objects that are used to display the sessions. As shown below, the Frame object controls the display of the shaded area.
• The View object is the visual aspect of a session document. One way you might consider the View object is to think of it as a tabbed view in the Reflection workspace. Because Reflection is a multiple document interface (MDI) application, it can have several views. In the workspace shown below, the View object controls the area displayed within the outline.
  

You can get the Frame from the Application object. The Frame object provides methods and properties for working with Views (the visible aspect of a session or Web document), and for working with the state, position, and dimensions of the Reflection main window (which is called the workspace).

When you get or create a new control, it isn't visible initially. To make the control visible, you must create a View object that is associated with the control (View objects always include a single embedded control).

You can identify a View the same way that you identify controls: by the instance ID, the name, the title text, or the file path of the underlying session document. The name property of a View is initially empty; you can set this property to any string to help identify the View object later.

Note: In the likelihood that multiple Views and controls will be created from a single document, you should use a unique identifier (such as the instance ID) to identify a particular View or control. For more information, see Getting Terminal and View Objects.

Working with events

The Reflection API supports a variety of programming event models. Many objects support asynchronous .NET events. Alternately, several synchronous wait methods are also available; these methods wait for specified conditions to happen. Other options for synchronous event handling include runtime status properties that provide the state information of their associated objects, such as the IsConnected property on the IbmTerminal object.

For a description of the namespaces in the Reflection API, see Namespaces .