Difference between revisions of "Object Inspector"

From Apache OpenOffice Wiki
Jump to: navigation, search
m (The Problem)
m (See Also)
Line 98: Line 98:
* [[Constructing_Helpers#Reflection_Helper|C++ Reflection Helper]]
* [[Constructing_Helpers#Reflection_Helper|C++ Reflection Helper]]
* Bernard Marcelly's [[Extensions_development_basic#Xray_tool|XRay tool description]] in this wiki.
* Bernard Marcelly's [[Extensions_development_basic#Xray_tool|XRay tool description]] in this wiki.
* [http://extensions.services.openoffice.org/project/MRI MRI an Object Inspector] written on Python from the Extension Website.
* [https://extensions.openoffice.org/project/MRI MRI an Object Inspector] written on Python from the Extension Website.
* [[IDL_Files_and_Cpp#Core_reflection_service__and_its_Interfaces| Core Reflection Service]]
* [[IDL_Files_and_Cpp#Core_reflection_service__and_its_Interfaces| Core Reflection Service]]
* [[IDL_Files_and_Cpp#Using_Java_Inspector|Using Java Inspector]] (C++ and AOOBasic)
* [[IDL_Files_and_Cpp#Using_Java_Inspector|Using Java Inspector]] (C++ and AOOBasic)

Revision as of 14:16, 1 October 2021

The Object Inspector is an OpenOffice.org extension created to help the developer to inspect arbitrary UNO-Objects. UNO provides a service-oriented API with abstract service descriptions exporting defined interfaces. The capabilities of a UNO Object do not open up to the developer at design time, mainly due to several "deficiencies". Please note that the Object Inspector is still under development.

The Problem

Generic interfaces like com.sun.star.beans.XPropertySet or com.sun.star.container/XIndexAccess 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 a runtime inspection is necessary to determine what respective capabilities a UNO object actually has. The Object Inspector is an OpenOffice.org 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.


The Object Inspector may be installed using the package manager (menu "Tools/Options") by adding the package from Inspector.oxt .

Together with the new package a new toolbar is added from which the object inspector may be started. The initial UNO object is the document of the 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 facets:

Methods of UNO objects are presented as subnodes below a "Method" node. All methods are listed below this node, no matter what their parental interfaces are.

Properties of UNO objects are presented as subnodes below 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.

Expanding any arbitrary subnode will inspect the UNO object that is represented by the node in the same way as described above.



Calling from a Basic Macro

The Object Inspector may 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

Sourcecode generation

The Object Inspector is also able to generate Sourcecode snippets that show how to:

  • query an interface (if necessary in the selected language)
  • invoke a method
  • retrieve a property value

Currently there are code generators for Java, C++, Python and Basic. The resulting code is not perfect, but should compile well. See Object Inspector Comparison.

IDL help

The user may retrieve help about selected nodes from the IDL files of the respective interface and service descriptions.


Source code

You will find the Object Inspector source code within the OpenOffice.org Subversion Repository:

 svn co svn://svn.apache.org/repos/asf/openoffice/trunk/main/odk/examples/java/Inspector/

The checked in source contains a complete NetBeans project, so that one can immediately start hacking around. Feel free to commit bugfixes and changes or contact cli(at)openoffice.org if you like to take over the project.

Known issues

The Object inspector is still under development and the following list points to some known unresolved defects.

  • Filtering is slow and uncomfortable as nodes are collapsing and need to be expanded manually
  • IDL help is not working (including context sensitive help)
  • C++ code not properly generated (it was better with previous version). Read more here particularly Java Inspector 2 section.

Future Enhancements

  • Invocation of methods with complex parameters should be implemented. It should be implemented in several steps
    • Implementation of Array parameters with primitive elements.
    • Implementation of structs.
    • Implementation of an input mask to refer to UNO-Objects as method parameters.
    • Consider multidimensional arrays as method parameters and for return values.
  • An additional UNO GUI should be created, so that the extension integrates well in OOo and NetBeans. The existing model can be easily adapted to another GUI, hopefully.
  • Interfaces that are exported by an UNO object although not being exported by any of the supported 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.
  • Add a "Container" meta node that can be expanded to retrieve information about Elements. This node is only applicable when the UNO object also depicts a container that exports interfaces like XIndexAccess.

See Also

Personal tools