Difference between revisions of "Porting example"
Line 1: | Line 1: | ||
− | === Step 1 Choose | + | === Step 1 Choose an object to port === |
− | I randomly picked the Filter object e.g. [http://api.openoffice.org/source/browse/*checkout*/api/helperapi/com/sun/star/helper/calc/XFilter.idl XFilter] in the helperapi, then | + | I randomly picked the Filter object e.g. [http://api.openoffice.org/source/browse/*checkout*/api/helperapi/com/sun/star/helper/calc/XFilter.idl XFilter] in the helperapi, then browsed the [http://api.openoffice.org/source/browse/api/helperapi/ helperapi] code. I find XFilter is implemented by [http://api.openoffice.org/source/browse/*checkout*/api/helperapi/impl/com/sun/star/helper/calc/FilterImpl.java FilterImpl.java] but it expects to be initialised by an [http://api.openoffice.org/source/browse/*checkout*/api/helperapi/com/sun/star/helper/calc/XAutoFilter.idl XAutoFilter] implementation [http://api.openoffice.org/source/browse/*checkout*/api/helperapi/impl/com/sun/star/helper/calc/AutoFilterImpl.java object] |
− | so already we need to think about providing an implementation for XFilter but also for XAutoFilter | + | so already we need to think about providing an implementation not only for XFilter but also for XAutoFilter |
− | looking at XAutoFilter.idl we see that there is a <tt>Filters(</tt> attribute/method that returns a [[Collection]] of Filters, so additionally I now realise I also need an implementation of the XFilters object. | + | looking at XAutoFilter.idl we see that there is a <tt>Filters()</tt> attribute/method that returns a [[Collection]] of Filters, so additionally I now realise I also need an implementation of the XFilters object. The XAutoFilter implementation is the key object that the others are accessed/provided from. After some searching through the source code I find this is an attribute of the [http://api.openoffice.org/source/browse/*checkout*/api/helperapi/impl/com/sun/star/helper/calc/SheetImpl.java SheetImpl] object |
so, to summarize, after initially choosing one object to have a crack at porting, I find in fact I actually need to provide implementations for the following interfaces | so, to summarize, after initially choosing one object to have a crack at porting, I find in fact I actually need to provide implementations for the following interfaces | ||
Line 10: | Line 10: | ||
* XAutoFilter | * XAutoFilter | ||
* XFilters | * XFilters | ||
− | and I need to add a new attribute to return an <tt>XAutoFilter</tt> implementation | + | and also I need to add a new attribute to return an <tt>XAutoFilter</tt> implementation |
+ | |||
+ | === Step 2 Port the idl files === |
Revision as of 11:49, 23 February 2007
Step 1 Choose an object to port
I randomly picked the Filter object e.g. XFilter in the helperapi, then browsed the helperapi code. I find XFilter is implemented by FilterImpl.java but it expects to be initialised by an XAutoFilter implementation object
so already we need to think about providing an implementation not only for XFilter but also for XAutoFilter
looking at XAutoFilter.idl we see that there is a Filters() attribute/method that returns a Collection of Filters, so additionally I now realise I also need an implementation of the XFilters object. The XAutoFilter implementation is the key object that the others are accessed/provided from. After some searching through the source code I find this is an attribute of the SheetImpl object
so, to summarize, after initially choosing one object to have a crack at porting, I find in fact I actually need to provide implementations for the following interfaces
- XFilter
- XAutoFilter
- XFilters
and also I need to add a new attribute to return an XAutoFilter implementation