Hi Gao,
gaozm wrote:
Hello Thomas:
Thank you for your help, I have found the right code places for the XML
import/export.
The functions are SAL_CALL ScFilterDescriptorBase::setFilterFields() and
SAL_CALL ScFilterDescriptorBase::getFilterFields(), the file path is
sc/source/ui/unoobj/datauno.cxx.
Do you think whether what I say is right?
I just did a fast check with the debugger, and yes, those locations
are right. In addition I also found
ScXMLDPConditionContext::getOperatorXML().
Apart from that I found out, that you also have to extend the switch
statement in line 991 of ScTableQuery::ValidQuery for the new
filter conditions.
In this context, please keep in mind, that you can also define filters
with the data pilot, but those filters contain less filter operators
than that of the standard filter.
When I add one case statement like case SC_CONTAINS: aField.Operator =
sheet::FilterOperator_CONTAINS; break; when compiling , the error shows
below:" 'FilterOperator_CONTAINS':is not a member of 'com:: sun:: star:: sheet' and
'FilterOperator_CONTAINS': undeclared identifier".
I have spent long time to solve the problem but found it is hard for me to
conquer it. Hope you give me some help, thank you.
The reason for your error is rather simple, namely that the new filter
operators are not part of the UNO enum
com::sun::star::sheet::FilterOperator.
Unfortunately you cannot extend an already published UNO enum,
and therefore you have to work around the problem.
I propose to introduce a new UNO constants group of type long, e.g.
com::sun::star::sheet::FilterOperator2 (probably you find a better
name), which contains the old and new filter operators.
A constant group has the advantage that it can be extended in the
future. You cannot simply exchange the old enum by the new constants
group in the calc code, because you need to stay compatible with the
UNO API and also old macros should still work.
Therefore you have to check all locations of com::sun::star::FilterOperator
in the UNO API. One sees, that it's used as member in the UNO struct
com::sun::star::sheet::TableFilterField.
Therefore one needs a second UNO struct, e.g.
css::sheet::TableFilterField2, which differs from
css::sheet::TableFilterField only in the filter operator
member, that means it contains the css::sheet::FilterOperator2 constants
group instead of the css::sheet::FilterOperator enum.
In addition you have to duplicate all UNO API methods, which have
css::sheet::TableFilterField as parameter or return value,
e.g. the methods getFilterFields() and setFilterFields() of the
css::sheet::XSheetFilterDescriptor interface. Here it makes sense to
introduce a css::sheet::XSheetFilterDescriptor2 interface, which can
be derived from css::sheet::XSheetFilterDescriptor.
For the implementation of the XML import/export you can then use the new
UNO interfaces/constants in the implementation. But please assure, that
all old UNO methods stay compatible.
As you see, all this is a huge amount of work, which is only necessary
due to the fact, that UNO enums cannot be extended. But I think we have
no other choice.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
