Difference between revisions of "Porting notes"

From Apache OpenOffice Wiki
Jump to: navigation, search
(Application Object)
(Calc Objects to port)
Line 58: Line 58:
 
| XAxisTitle.idl || xxxx  ||  ||  ||
 
| XAxisTitle.idl || xxxx  ||  ||  ||
 
|-
 
|-
| XCalc.idl || xxxx  || ||  || This is not a 'real' object but in a collection of global method/attributes that probably should be part of the XApplication.idl interface
+
| XCalc.idl || xxxx  || not required for porting see [[Application Object]] ||  || This is not a 'real' object but in a collection of global method/attributes that probably should be part of the XApplication.idl interface
 
|-
 
|-
 
| XCharts.idl || xxxx  ||  ||  ||
 
| XCharts.idl || xxxx  ||  ||  ||

Revision as of 11:38, 22 March 2007

Things to watch out for

  • The mapping of the vba constants is different. Take for example the xlGuess constant, in VBA it's fully qualified name is Excel.XlYesNoGuess.xlGuess, in the helperapi it's com.sun.star.helper.constant.XlYesNoGuess.xlGuess and in oovbaapi it's org.openoffice.excel.XlYesNoGuess.xlGuess
  • All objects in the helperapi extend HelperInterfaceAdaptor, nothing similar (yet) exists in oovbaapi so this can be ignored in the implementation
  • There are a quite few helper classes in the helperapi project e.g. RangeHelper.java they shouldn't be confused with the actual implementation objects we wish to port.
  • classes and idl files of the same name can exist in multiple namespaces and this can be confusing. Because the helperapi was written with both the word and excel api(s) in mind there can be classes that share a common implementation and interfaces e.g.
    • com/sun/star/helper/calc/XShape.idl
    • com/sun/star/helper/common/XShape.idl
    • com/sun/star/helper/writer/XShape.idl
  • Collections, these are handled differently see implementing a vba Collection in oovbaapi
  • Every helperapi idl method defines BasicErrorException which allows and api method to transfer an error code and associated string paramater to basic.

Hints for porting idl

Objects with Default Properties

This is something not handled by the helperapi but something you should be aware of when implementing a vba compatibility object. What is a default property, an example probably explains the concept better.

Range("a1") = "text"

is a short cut for

Range("a1").Value = "text"

Value is a default property in the example above. We can provide similar behavior in basic with a compatibility api object ensuring the object implements XDefaultProperty.idl

Objects with Default Method

Similar to above some vba objects have a default method e.g. the Collection object

set col = Sheets
msgbox col(1).Name

is a short cut for

set col = Sheets
msgbox col.Item(1).Name

Item is a default method in the example above. We can provide similar behavior in basic with a compatibility api object ensuring the object implements XDefaultMethod.idl

Porting Collection objects

Generally all collection objects have a Count and an Item method and additionally the behaviour mentioned above. Also Collection objects can be used in a For Each loop. To cater for that a helper implementation object ScVbaCollectionBaseImpl provides the necessary information to the basic runtime to allow it to provide the classic vba Collection class syntax support. It also requires to be initialised by an XIndexAccess implementation. Additionally the class inheriting from ScVbaCollectionBaseImpl must provide the translation between the object iterated ( via XIndexAccess ) and the corrosponding compatibilty object returned to openoffice basic via the the createCollectionObject method.

A example of a ported Collection object can be found in the Porting example section

Calc Objects to port

Object helperapi implementation name Porting stared by Status Notes
XAutoFilter.idl AutoFilterImpl there is a partial (untested) implementation in the porting example section, would be nice for some one to finish
XFilter.idl FilterImpl.java see above.
XFilters.idl FiltersImpl.java see above.
XAxes.idl xxxx
XAxis.idl xxxx
XAxisTitle.idl xxxx
XCalc.idl xxxx not required for porting see Application Object This is not a 'real' object but in a collection of global method/attributes that probably should be part of the XApplication.idl interface
XCharts.idl xxxx
XChartTitle.idl xxxx
XDataLabel.idl xxxx
XDataLabels.idl xxxx
XFormatCondition.idl xxxx
XFormatConditions.idl xxxx
XFormat.idl xxxx
XHPageBreak.idl xxxx
XHPageBreaks.idl xxxx
XName.idl xxxx
XNames.idl xxxx
XPageBreak.idl xxxx
XPageSetup.idl PageSetupImpl zhang
XPane.idl PaneImpl Jiao.Jianhua calc complete
XPoint.idl xxxx
XPoints.idl xxxx
XProtection.idl xxxx
XQueryTable.idl xxxx
XQueryTables.idl xxxx
XShape.idl xxxx jiao.jianhua
XShapes.idl xxxx
XStyle.idl xxxx
XStyles.idl xxxx
XTitle.idl xxxx
XVPageBreak.idl xxxx
XVPageBreaks.idl xxxx

Common Objects to port

Object helperapi implementation name Porting stared by? Status
XAutoFilter.idl xxxx
XPictureFormat xxxx
XColorFormat xxxx
XPosSize xxxx Jiao.Jianhua implemented in org.openoffice.XControl
XWindow xxxx
XFileSearch xxxx
XWrapFormat xxxx
XFillFormat xxxx
XShapeRange xxxx
XFoundFiles xxxx
XLineFormat xxxx
XTextFrame xxxx

Missing attributes/methods to port

Application Object

Personal tools