Hi Noel,
On Fri, 2007-07-20 at 09:53 +0100, Noel Power wrote:
> Hi Kohei
>
> Kohei Yoshida wrote:
> > These data structures are exchanged via XExtendedSheetFilterDescriptor,
> > which is exported by the existing SheetFilterDescriptor service.
> >
> > interface XExtendedSheetFilterDescriptor
> > {
> > void begin();
> >
> > void commit();
> >
> > void addFilterFieldNormal(
> > [in] sheet::TableFilterFieldNormal aField );
> >
> > void addFilterFieldMultiString(
> > [in] sheet::TableFilterFieldMultiString aField );
> >
> > TableFilterFieldType getFirstType();
> >
> > TableFilterFieldType getNextType();
> >
> > void getFilterFieldNormal(
> > [out] sheet::TableFilterFieldNormal aField );
> >
> > void getFilterFieldMultiString(
> > [out] sheet::TableFilterFieldMultiString aField );
> > };
> >
> mmm this seems to break your previous effort to ease making this service
> easily extensible by locking in the FilterField types into the
> interface, so perhaps something like
> Any getFilterField( [in] TableFilterFieldType aType ) would do
> achieve what you want?
Yes, I agree that using Any will make the API a little cleaner and will
allow future extension. Thanks for the input!
(I admit I fogot about the existance of 'Any' when I designed
this.....was perhaps thinking too much in C++ mode.)
>
> Also the getFirstType() and getNextType() seem to indicate some sort of
> access to the underlying container but it seems that specific access to
> the elements of the container isn't possible ( or perhaps you just don't
> show some sort of XSomethingAccess interface that is part of the service )
Good point. Some sort of index access is certainly called for. Let me
think about that.
> > There is also an enum type css.sheet.TableFilterFieldType:
> >
> > enum TableFilterFieldType
> > {
> > NORMAL,
> > MULTI_STRING,
> > NONE
> > };
> >
> for extensibility probably best to steer away from enums ( iirc the
> upper limit of the enum range of values is hardcoded in the generated
> c++ files ) and use constants instead
Agreed, although the upper limit of the enum range seems to be large
enough for future extensions (SAL_MAX_ENUM = 0x7fffffff = 2147483647!).
But for ultimate future extensibility we should probably use constants,
I suppose.
> On a side note something that I came across that would be great to
> address in an update to the api is the ability to 'unfilter' a field (
> e.g. the equivelant of selecting all in the drop down filter list )
> Perhaps I missed something but I never found how to do this with the api
> ( maybe someone can elighten me about that, but when I last looked at
> this it seems that when you delete a FilterField via the api then the
> bDoQuery for the associated ScQueryEntry is set to false, later on when
> refresh is called in ScDBDocFunc::RepeatDB such queries are not then
> passed to ScDBDocFunc::Query which would then do the 'all' for you )
Well, it's easy to add such support on my end. All I need to do would
be to add a method that turns bDoQuery off for the specified index.
One thing I still need to check is, when a FilterField gets deleted, do
we need to just set the bDoQuery flag to false and leave the deleted
entry at its index position, or do we need to delete that, and push
everything that comes below that index position up?
Kohei
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
