Difference between revisions of "Object Inspector"

From Apache OpenOffice Wiki
Jump to: navigation, search
m (See Also)
Line 53: Line 53:
 
Illustration 1 Object Inspector
 
Illustration 1 Object Inspector
  
== '''Problems and Todos to be further specified''' ==
 
  
Interfaces that are exported by an Uno-Object although not being exported by any of the suported services should be distinguished from the other interfaces. There should be displayed some kind of alert as their usage is potentially hazardous, because it is merely based on an implementation detail.
+
== Calling from a Basic Macro ==
 +
The Object Inspector may also be instantiated within a Basic script as can be seen in the following examplary script, where the current document is inspected:
  
It has to be specified how object parameters of methods are identified on the method invocation. Basically the idea is to copy these objects from its respective treenode and paste the so called treepath of the node into the textfield of the inputmask for the paramter values.
+
Sub Main
 +
oInspector = createUnoService("org.openoffice.InstanceInspector")
 +
oInspector.inspect(ThisComponent, "My Document")
 +
End Sub
  
Probably the user will want to invoke the method with different parameters. For each invocation an own subnode could be generated containing all relevant information about the paramter values.
 
  
Source-Code generation: The question is how to identifiy the entry object. Basically this can be any Uno object. A solution could be to pass this object as parameter to the generated method like:
+
== Source-code generation ==
  
  
  public static void main(XModel _xModel){
+
The Object inspector now is also capable to generate Source Code that is needed to create the Object or primitve value returned of the current selected node. Starting from an the root object, denoted as „<ENTRYOBJECT>“, all needed variables are declared and defined automatically as well as import statements(for C++ include statements).
    XNameAccess xNameAccess = _xModel.getTextTables()
+
 
    Object oSwXTextTable = xNameAccess.getByName(„Table1“)
+
 
}
+
== '''Problems and Todos to be further specified''' ==
 +
 
 +
Interfaces that are exported by an Uno-Object although not being exported by any of the suported services should be distinguished from the other interfaces. There should be displayed some kind of alert as their usage is potentially hazardous, because it is merely based on an implementation detail.
  
 +
The Object Inspector should be able to store data persistently in the registry. Such data would be a) the path to a local SDK -installation, which would then be preferrably used to get help content or b) configuration data such as the default programming language.
  
where „_xModel“ is the root object of the treeview control. Another option is to facilitate fix code segments for certain Uno-objects, like „ThisComponent“ as a StarBasic code segment for an Office document.  
+
Treenodes representing methods currently can only be called once which is not sufficient for methods that may return diferent return values. Therefor it must be defined how this behaviour is implemented in the treeview control.
Source code generation should consider all the different aspects of the different language bindings when it comes to  
+
Currently not all variable types are handled correctly. One big issue in this context is the correct assignment of object variables as method parameters. It has to be specified how the object values of the parameters are defined. It will result in a reference setup by the path of the respective treeview control node that the user can select. By means of the context menu the userer then has the possibility to copy the path to the dialog where the method parameters can be entered.
generation of import statements (Java) or header includes (C++);
+
generation of variable declarations: Probably it makes sense to offer an option where variable are only declared with a public scope instead of a local scope. It should be kept in mind that StarBasic does not need variable declaration in its „Option Explicit“ mode.
+
appending source Code statements to one another in order to combine them to complete script skeletons. At least this could be added as an option.
+
  
 +
Sourcecode in C++ or OpenOffice.org Basic is not yet implemented.
  
 
The design of the icon set should be overworked and extended in a final step
 
The design of the icon set should be overworked and extended in a final step

Revision as of 15:01, 22 November 2006

The new Object Inspector

The Object Inspector is an OpenOffice.org extension that is to help the developer to inspect arbitrary Uno-Objects. As Uno provides a service-oriented API with abstract service descriptions exporting defined interfaces the capabilities of a Uno Object does not open up to the developer at design time mainly due to several „deficiencies“. The Object Inspector is still under development.

The Problem

Generic interfaces like „XPropertySet“ or „XIndexAcess“ do not define their exact return value. Service descriptions that export these interfaces mostly do not contain such information either.

It is not always clear at design time which services a Uno-object actually supports.

Documentation bugs. As service descriptions do not always show up all actually exported interfaces or properties there may be a certain difference between the theoretical and the practical capabilities of a Uno object.

The Solution

The conclusion is that it has be be inspected during runtime what respective capabilities a Uno-Object actually has. The new Object Inspector is an OpenOffice extension that has been evolved from the ancient instance inspector that is part of the OpenOffice.org SDK. It displays the total capabilities of a „living Uno-object“ such as all supported services, exported interfaces, and their respective methods and properties in a treeview window.


Usage

The object inspector may be installed using the package manager (menu „Tools/Options“) by adding the package from [1] . Together with the new package a new toolbar is added from which the object inspector may be started. The object inspector consists of a menu-controlled resizable dialog with a treeview control embedded in a tab pane (see Illustration 1: Object Inspector). The treeview control is to inspected a Uno-object. The initial Uno-Object is the document of the currently active frame. The Uno-object of this document is represented by the root node of the treelist control. Expanding this node will create subnodes referencing all subordinate objects, properties, methods and other values of the root object. All this information is presented in various facettes:

Methods of Uno-objects are presented as subnodes under a „Method node“. All methods are listed under this node, no matter what their parental interfaces are. Expanding nodes that denote a method of a Uno-object will invoke the method and if necessary a dialog with an input mask for the method parameters will appear.

Properties of Uno-objects are presented as subnodes under a „Properties“ node.

„Interface“ nodes offer a view to all methods by arranging them under their respective interface.

„Service“ nodes offer a view to all supported services of a Uno-object and their respectively exported interfaces and properties. "Container" nodes may be expanded to retrieve information about Elements. This node is only applicable when the Uno-objects also depicts a container that exports interfaces like "com.sun.star.container.XIndexAccess"

Expanding any arbitrary subnode will inspect the Uno-object that is represented by the node in the same way as described above. Subnodes that describe methods will invoke this method at the Uno-object. If parameters have to be supplied these have to be delivered by the user in a special dialog that opens up when the node is expanded.

The menubar consists of several menus:

„File“ menu to remove tab panes and to quit the object inspector.

„Inspect“ menu in order to determine the Uno-objects to be inspected. Clicking on such a menu item will open a new tab pane for a certain Uno-object. Offered Uno-objects are derived from the following items in this menu: empty documents of all given application. text document, empty spreadsheet, empty presentation, empty drawing. Selecting one of these menu entries opens a new tabpane and loads an empty hidden application document. Menu entries for the so-called T-Docs („transient documents“). T-Docs describe the currently opened documents. The object inspector is started with the currently active document as the to-be inspected Uno-object. The currently selected object. This menu entry references the Uno-object of the currently selected node. This option is explicitly helpful in vast object hierarchies where the user can easily loose track. The global service manager, that can be used to instantiate a great variety of services.

„View“ menu: Developers may prefer different views on the respective Uno-Objects depending on the momentary situation and the used programming language. For example StarBasic developers are naturally not very interested what interfaces a Uno object supports as they use the methods directly. On the other hand in StarBasic many „getter“ and „setter“ methods are implemented as properties and should optionally turn up underneath the „Properties“ node. This menu and its underlying functionality has not yet been implementd nor has it been specified.

„Options“menu to be used to set all kind of options. It is not yet implemented.

„Help“ menu to aquire help about Uno-objects behind selected nodes. Also via shortcut F1 the browser will open a help document about the used interface or service of a Uno-object , that is referenced by a selected node.


Filtering

As can be see in Illustration 1: Object Inspector a filter can assist a determined search for subnodes. It also helps to keep the overview especially in large hierarchies.

File:Object Inspector.png

Illustration 1 Object Inspector


Calling from a Basic Macro

The Object Inspector may also be instantiated within a Basic script as can be seen in the following examplary script, where the current document is inspected:

Sub Main oInspector = createUnoService("org.openoffice.InstanceInspector") oInspector.inspect(ThisComponent, "My Document") End Sub


Source-code generation

The Object inspector now is also capable to generate Source Code that is needed to create the Object or primitve value returned of the current selected node. Starting from an the root object, denoted as „<ENTRYOBJECT>“, all needed variables are declared and defined automatically as well as import statements(for C++ include statements).


Problems and Todos to be further specified

Interfaces that are exported by an Uno-Object although not being exported by any of the suported services should be distinguished from the other interfaces. There should be displayed some kind of alert as their usage is potentially hazardous, because it is merely based on an implementation detail.

The Object Inspector should be able to store data persistently in the registry. Such data would be a) the path to a local SDK -installation, which would then be preferrably used to get help content or b) configuration data such as the default programming language.

Treenodes representing methods currently can only be called once which is not sufficient for methods that may return diferent return values. Therefor it must be defined how this behaviour is implemented in the treeview control. Currently not all variable types are handled correctly. One big issue in this context is the correct assignment of object variables as method parameters. It has to be specified how the object values of the parameters are defined. It will result in a reference setup by the path of the respective treeview control node that the user can select. By means of the context menu the userer then has the possibility to copy the path to the dialog where the method parameters can be entered.

Sourcecode in C++ or OpenOffice.org Basic is not yet implemented.

The design of the icon set should be overworked and extended in a final step

Part of the functionality should be provided by a context menu mainly to be used to invoke actions from treenodes, like inspecting treenodes' Uno-objext in a new tabpane or copy Uno-objects from a treenode to the parameter invocation input mask.

Instead of obtaining the help files from the internet at www.openoffice.org it could optionally be retrieved from a local sdk installation. The path to this installation would have to be set only once and the object inspector would be independent of internet access.

Implementation of different views on the inspected Uno-objects as already being mentioned above in the description of the „View“ menu

See Also

Current CWS Name: sdkinspector
Personal tools