Issue 35579 - Standard filter requires more options..
Summary: Standard filter requires more options..
Status: CLOSED FIXED
Alias: None
Product: Calc
Classification: Application
Component: ui (show other issues)
Version: 680m79
Hardware: All All
: P3 Trivial with 46 votes (vote)
Target Milestone: ---
Assignee: oc
QA Contact: issues@sc
URL:
Keywords: oooqa
: 43156 46236 73204 75543 75774 76311 84874 89549 90605 90923 (view as issue list)
Depends on:
Blocks: 72764 77677 15522 90135 102872
  Show dependency tree
 
Reported: 2004-10-15 05:36 UTC by sragavan
Modified: 2013-08-07 15:14 UTC (History)
27 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
porposed patch against OOO113 (10.45 KB, patch)
2004-10-15 05:37 UTC, sragavan
no flags Details | Diff
make it more usable & familiar. (3.53 KB, patch)
2005-03-22 14:02 UTC, mmeeks
no flags Details | Diff
much improved version ... (7.73 KB, patch)
2005-04-11 12:33 UTC, mmeeks
no flags Details | Diff
Kohei's patch copied from issue 43156 that is to be closed as duplicate. (6.72 KB, patch)
2006-02-13 17:33 UTC, ooo
no flags Details | Diff
Updated with nn's requirements. In my opinion it doesnot matter (to the end user) we do it through regex or otherwise - the usability is what matters. (4.38 KB, patch)
2006-02-18 16:31 UTC, muthusuba
no flags Details | Diff
Obsoletes Kohei's 20060212 patch; ignores leading/trailing whitespace, adds Excel import/export support. (16.70 KB, text/plain)
2007-08-09 20:12 UTC, jpryor
no flags Details
Adds file format support to save the new filter settings into .ods files. (8.88 KB, text/plain)
2007-08-09 20:23 UTC, jpryor
no flags Details
Previous version had a compilation error (sorry). This is the correct sc-standard-filter-options.diff patch. (15.26 KB, text/plain)
2007-08-10 20:45 UTC, jpryor
no flags Details
Add some filter-conditions and change the layout to the new dialog style by shifting OK/Cancel/Help buttons (83.72 KB, text/plain)
2008-01-07 03:10 UTC, gaozm
no flags Details
A patch (17.01 KB, text/plain)
2008-01-07 05:20 UTC, lvyue
no flags Details
I have modified the last patch according to tbe's comments. Please check it. And for the ODF part, we stiil need some time. (18.73 KB, text/plain)
2008-01-10 04:26 UTC, lvyue
no flags Details
I have extended the UNO API (2.35 KB, text/plain)
2008-01-17 07:52 UTC, gaozm
no flags Details
I have extended the UNO API (4.55 KB, text/plain)
2008-01-17 07:54 UTC, gaozm
no flags Details
I have extended the UNO API (2.71 KB, text/plain)
2008-01-17 07:55 UTC, gaozm
no flags Details
patch2 (19.81 KB, text/plain)
2008-01-17 08:01 UTC, lvyue
no flags Details
Extend the UNO API (4.98 KB, text/plain)
2008-01-18 04:46 UTC, gaozm
no flags Details
Extend the UNO API (3.13 KB, text/plain)
2008-01-18 04:47 UTC, gaozm
no flags Details
Extend the UNO API (2.61 KB, text/plain)
2008-01-18 04:48 UTC, gaozm
no flags Details
A patch about the XML import/export (11.64 KB, text/plain)
2008-01-29 08:23 UTC, gaozm
no flags Details
A new patch about the XML import/export (1) (4.93 KB, text/plain)
2008-01-30 07:53 UTC, gaozm
no flags Details
A new patch about the XML import/export (2) (3.32 KB, text/plain)
2008-01-30 07:55 UTC, gaozm
no flags Details
A new patch about the XML import/export (3) (2.85 KB, text/plain)
2008-01-30 07:56 UTC, gaozm
no flags Details
A new patch about the XML import/export (4) (12.83 KB, text/plain)
2008-01-30 07:58 UTC, gaozm
no flags Details
A patch about the XML import/export (offapi) (13.17 KB, text/plain)
2008-01-31 08:19 UTC, gaozm
no flags Details
A patch about the XML import/export (sc) (9.65 KB, text/plain)
2008-01-31 08:22 UTC, gaozm
no flags Details
A patch about the XML import/export (offapi) (1) (13.96 KB, text/plain)
2008-02-18 08:31 UTC, gaozm
no flags Details
A patch about the XML import/export (sc) (1) (10.29 KB, text/plain)
2008-02-18 08:33 UTC, gaozm
no flags Details
A patch about the XML import/export (xmloff) (1) (2.65 KB, text/plain)
2008-02-18 08:35 UTC, gaozm
no flags Details
A new patch. the patch to the XML import/export (xmloff) (1) above is wrong. (2.00 KB, text/plain)
2008-02-19 08:09 UTC, gaozm
no flags Details
A new patch. the patch to the XML import/export (xmloff) above is wrong (2.00 KB, text/plain)
2008-02-25 02:59 UTC, gaozm
no flags Details
Another patch about the XML import/export (sc) (20.01 KB, text/plain)
2008-03-11 09:41 UTC, gaozm
no flags Details
Another patch about the XML import/export (offapi) (11.91 KB, text/plain)
2008-03-11 09:43 UTC, gaozm
no flags Details
What about this patch about the function ScXMLExportDatabaseRanges::WriteFilterDescriptor()? (27.08 KB, text/plain)
2008-03-13 06:51 UTC, gaozm
no flags Details
A patch about the XML import/export。 (40.51 KB, text/plain)
2008-03-18 09:36 UTC, gaozm
no flags Details
A patch about issue 35579 (72.23 KB, text/plain)
2008-04-30 05:35 UTC, gaozm
no flags Details
A patch about vbarange.cxx (17.49 KB, text/plain)
2008-05-06 04:43 UTC, gaozm
no flags Details
A new patch about the file vbarange.cxx (17.63 KB, text/plain)
2008-05-07 08:30 UTC, gaozm
no flags Details
A new patch about issue 35579. (93.43 KB, text/plain)
2008-05-12 04:53 UTC, gaozm
no flags Details
A complete patch to issue 35579. (90.53 KB, text/plain)
2008-06-12 09:19 UTC, gaozm
no flags Details
Update the patch. (76.39 KB, text/plain)
2009-03-25 09:38 UTC, yonggang.mao
no flags Details
patch 2, based on DEV300m49. (66.31 KB, text/plain)
2009-06-03 03:59 UTC, lvyue
no flags Details
Updata the SpecificationDocument of issue35579. (65.85 KB, text/plain)
2009-06-05 09:25 UTC, gaozm
no flags Details
TestCaseSpecification (12.36 KB, text/html)
2009-07-22 12:15 UTC, oc
no flags Details
Testdocument for Test Case Specification (7.53 KB, application/vnd.oasis.opendocument.spreadsheet)
2009-07-22 12:15 UTC, oc
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description sragavan 2004-10-15 05:36:13 UTC
Options like Begins with, ends with are required in standard filter to be more
usable. Also its better to have a provision to say search whole cell here
instead in the tools->options->Spreadsheet
Comment 1 sragavan 2004-10-15 05:37:53 UTC
Created attachment 18415 [details]
porposed patch against OOO113
Comment 2 frank 2004-10-15 09:18:09 UTC
Hi Niklas,

please have a look.

Frank
Comment 3 mmeeks 2005-03-22 14:01:33 UTC
Attaching our patch vs. m79, updating various fields.
Comment 4 mmeeks 2005-03-22 14:02:06 UTC
Created attachment 24154 [details]
make it more usable & familiar.
Comment 5 niklas.nebel 2005-03-22 15:51:42 UTC
For 2.0 it's too late to change strings that have to be translated.

As-is, the patch breaks the DataPilot filter dialog (which uses the same
ScQueryOp enum).

Generally, this is an enhancement that needs a specification. One might want to
detect the regular expression string and select the new list box entries again
when the dialog is opened. The automatic enabling of regular expressions might
be a bit surprising, but I guess we can live with that.

Falko, any comments? Do we want it for 2.0.1?
Comment 6 falko.tesch 2005-04-01 08:08:53 UTC
Yes. Target re-set.
Comment 7 mmeeks 2005-04-11 12:33:42 UTC
Created attachment 24919 [details]
much improved version ...
Comment 8 mmeeks 2005-04-11 12:36:32 UTC
The much improved version appends to the enum to avoid breaking languages
without the right strings, it also adds 'contains', 'does not contain'. Thanks
to Muthu.
Comment 9 frank 2005-04-14 14:44:10 UTC
*** Issue 46236 has been marked as a duplicate of this issue. ***
Comment 10 niklas.nebel 2005-08-23 16:20:22 UTC
Sorry for the delay with this issue.

Introducing new filter operators would also require extensions to the API and
the file format (filter criteria are saved with a file, as part of the database
range). The original suggestion was to change just the dialog, and construct
regular expressions that could be processed without changes to other parts of
the code, thus enabling a quick solution. With the last patch, you're leaving
that path. Was that intended?

Having a specification beforehand would help to prevent such problems. For now,
it looks like all we can do is retarget this to "later".
Comment 11 kami911 2006-02-10 00:12:41 UTC
Same issue:
http://qa.openoffice.org/issues/show_bug.cgi?id=43156
Comment 12 ooo 2006-02-13 17:33:05 UTC
Created attachment 34120 [details]
Kohei's patch copied from issue 43156 that is to be closed as duplicate.
Comment 13 ooo 2006-02-13 17:37:02 UTC
*** Issue 43156 has been marked as a duplicate of this issue. ***
Comment 14 ooo 2006-02-13 17:54:36 UTC
The new patch from Kohei goes into the direction what I suggested in issue
43156. Funnily enough this is somewhat contradictory to what Niklas suggested
here, to use regular expressions for the new conditions because that wouldn't
need file format or API changes. To my view, we're implementing these options
mainly because the user does not know how to handle regular expressions.
Enabling regular expressions again for that purpose and requiring from the user
to properly escape his search string is a bit senseless, IMHO.

The next obsatcle is the change necessary to the ODF file format, where in
section  8.7.3 for the table:filter-condition element the table:operator
attribute has defined values for the already existing operators. This needs to
be changed or a new attribute be specified. Not clear yet how to proceed there.
Comment 15 muthusuba 2006-02-18 16:31:54 UTC
Created attachment 34263 [details]
Updated with nn's requirements. In my opinion it doesnot matter (to the end user) we do it through regex or otherwise - the usability is what matters.
Comment 16 kyoshida 2006-02-18 16:59:59 UTC
I think we need to have a concensus from the core developers before we proceed
any further.  Personally I tend to agree with Eike on this, that forcing the
regex bit on even it was not selected in the dialog would be a bit confusing,
and I don't know how that would improve the usability of this functionality. 
But the difference between the two implementations are small enough that I would
be fine with either direction.

nn and er: What do you guys think?
Comment 17 kyoshida 2006-02-18 17:01:10 UTC
s/concensus/consensus/g
Comment 18 kami911 2006-06-10 14:15:57 UTC
Kohei - your patch works well :o) Can we force of integration to OOo?
Comment 19 kyoshida 2006-06-12 15:09:16 UTC
kami_: This is one of those issues that require a file format change according
to er, so someone from Sun will be able to answer that question.  ooo-build has
mmeeks' patch already commited.  I've contacted mmeeks to see if we can use mine
for ooo-build.
Comment 20 kpalagin 2006-08-01 15:20:11 UTC
Dear developers,
any progress on this very important enhancement?
Comment 21 mmeeks 2006-08-01 16:04:30 UTC
I guess the problem is "smells like a file format change" - then life becomes
even more unpleasant than it normally is :-) so - most sane people are not going
to touch this bug ;-) That's my suspicion anyway.
Comment 22 kpalagin 2006-08-01 19:20:49 UTC
IMO, this functionality is of such importance that all options are viable:
1. change just interface so that user can filter, but not save condition.
2. modify GUI to construct RegEx for user and save RegEx. Users will quickly 
learn to write RegExs themselves.
3. Save condition only in foreign format, not .ods.
4. Change file format.
5. Something else.
Options 1-3 allow to postpone change until later.
What are the implications of file format change? Earlier version will be 
unable to open files, created by later? Or just filter settings will be lost?
Comment 23 ooo 2006-08-02 13:32:12 UTC
Michael was quite right with the nose approach ;-)

Kpalagin,

> IMO, this functionality is of such importance that all options are viable:
> 1. change just interface so that user can filter, but not save condition.

Filter settings are saved with defined database ranges, so wouldn't
match the actual data view if document was reloaded. Not saving just the
new settings would probably quite confuse a user.

> 2. modify GUI to construct RegEx for user and save RegEx. Users will quickly 
> learn to write RegExs themselves.

You'd introduce an even longer lasting project..

> 3. Save condition only in foreign format, not .ods.

You wouldn't really recommend that, would you?

> 4. Change file format.

The cleanest option, just takes it time.

> 5. Something else.

Nice offer.

> Options 1-3 allow to postpone change until later.
> What are the implications of file format change? Earlier version will be 
> unable to open files, created by later? Or just filter settings will be lost?

Filter settings would be lost (or garbled at worst) and not match the
filtered data. But that's not the point in this case. Modifying the
document format means having to undergo the OASIS process to review and
accept changes. It just takes its time. But I'll propose it.

  Eike
Comment 24 kpalagin 2006-08-02 14:20:01 UTC
Thanks a lot.
Any chance that we will see progress in Issue 35579?

WBR,
K. Palagin.
Comment 25 muthusuba 2006-08-02 15:05:02 UTC
er,
  Why do you feel doing it regex way is not a good way? 
I feel we can just add note saying 'that will create a regular expression'? And
when the user re-opens the dialog he/she can actually see the regular expression
constructed.

Thanks,
muthusuba
Comment 26 ooo 2006-08-02 17:08:49 UTC
Muthu,

> Why do you feel doing it regex way is not a good way? 

Because it obscures things by modifying the user's input. It's quite
attractive for simpler cases but may be cumbersome in more complicated
expressions.

> I feel we can just add note saying 'that will create a regular
> expression'?

And silently escape an "ends with" search input of
"my $.02 (maybe more)" to "my \$\.02 \(maybe more\)$"
Not that we might introduce errors in escaping the input ;-)

> And when the user re-opens the dialog he/she can actually see the
> regular expression constructed.

What if the user not familiar with regexps then would like to edit the
content to search for a slightly modified string?

It will get more twisted once we implement the simple DOS style "use
* and ? wildcards" that people know from Excel as document option; ends
with "on?y*.*" would change to "on.y.*\..*$". Just explain that to the
user.

We should remember the original input and setting anyway to be able to
save it in Excel format. And once saved to and reloaded from ODF format
it would be lost. We could reconstruct it from the regexp, but doing
this in roundtrips does not sound very appealing.

Another aspect is performance. A regexp search is ways slower than
a simple string search.

So I clearly recommend the clean solution of new table:operator
attributes for the table:filter-condition element.

  Eike
Comment 27 kpalagin 2006-09-03 10:24:17 UTC
Eike,
any progress on this issue?
Regards,
K. Palagin.
Comment 28 ooo 2006-10-18 17:59:40 UTC
Notified the ODF chair of the need for additional values for the table:operator
in table:filter-condition of section 8.7.3 ODF.
Comment 29 kpalagin 2006-10-18 20:39:06 UTC
Thank you, thank you, thank you!!!
Is there a way for regular users to track status and influence the timing and 
result? How the process of introducing such changes works?

With best regards,
K. Palagin
Comment 30 ooo 2006-10-19 12:19:03 UTC
You can't influence the timing or results, but you may follow the entire
ODF work by using the public resources available, see
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office
and the TC's mailing list in the archives at
http://www.oasis-open.org/archives/office/

The process generally is that a change is suggested, discussed, phrased,
an XML schema created, and together with other changes voted on for the
next version of the standard.

  Eike
Comment 31 utomo99 2006-11-19 09:12:56 UTC
the patch already exist for long time and improved also. 
please consider the target maybe such as OOo 2.2 or 2.x please. if possible. 
Thanks
Comment 32 kpalagin 2007-01-06 20:40:11 UTC
*** Issue 73204 has been marked as a duplicate of this issue. ***
Comment 33 graemenelson 2007-02-10 01:19:55 UTC
I don't see why it needs to be a file format issue.  How about this approach...

(Note: please be aware that I am note sufficiently familiar with the code module
divisions to be certain of naming the technically right portion at each point of
my explanation.)

Filter option of "Contains" transparently uses regex to do the job (ditto for
"Begins with" and "Ends with" if they are also adopted).
- When user selects "Contains", Calc/filter code transparently adds regex
strings to user search string for processing/saving.
- When reading from file, Calc/filter code recognizes the regex strings and
present it to user as "Contains".

Support for "simple wildcards" could be done in a similar way, with them
presented as an alternative option to regex on the dialogue.  Alternatively,
"simple wildcards" could be the default and are disable when regex support is
chosen.  (The latter would maintain consistency with current regex selection
requirement.)

The performance impact of these string detections on loading should be
insignificant, i.e. totally unnoticeable to the user, even on slow hardware. 
And from my limited knowledge of programming, the coding requirements should be
small also.

Discard these ideas if you want, I just thought that they were worth considering
as an alternative that would not require a file format change for the sake of
one application, especially when the change to the file format is arguably
unnecessary.
Comment 34 kpalagin 2007-03-23 20:21:48 UTC
*** Issue 75543 has been marked as a duplicate of this issue. ***
Comment 35 kpalagin 2007-03-28 15:04:20 UTC
*** Issue 75774 has been marked as a duplicate of this issue. ***
Comment 36 ramanal 2007-03-29 02:22:39 UTC
Hi, I vote for this because my users need to use text filtering options. I can
do regex, but not my users, and it will take long training session to teach them
RegeX for simple thing they can do in Excel in few seconds. 



Ramanal
Comment 37 ramanal 2007-03-29 03:50:22 UTC
Maybe a regex builder needed? 
So the user do not need to know regex, just fill in the form and then see the
result.

regards,
Ramanal
Comment 38 frank 2007-04-13 14:53:17 UTC
*** Issue 76311 has been marked as a duplicate of this issue. ***
Comment 39 ooo 2007-04-16 12:34:24 UTC
FYI, status update:
The file format change was accepted by the OASIS OpenDocument Technical
Committee to be part of the next ODF version, which probably will be out
by the end of this year.
Comment 40 niklas.nebel 2007-06-08 14:31:28 UTC
With the file format being extended for this, we can do something like in
Kohei's patch. It still has to be expanded to actually read and write the new
operators at load/save.
Comment 41 jpryor 2007-08-09 20:12:15 UTC
Created attachment 47444 [details]
Obsoletes Kohei's 20060212 patch; ignores leading/trailing whitespace, adds Excel import/export support.
Comment 42 jpryor 2007-08-09 20:20:13 UTC
The 2007-08-09 patch builds upon Kohei's latest patch to ignore leading/trailing
whitespace within cells and to add Excel import/export support for autofilters
that use begins-with, ends-with, contains, and does-not-contain.

The leading/trailing whitespace change is to make filtering more user-friendly.
 If the user has the rows:

  'foo'
  ' foo'

A search for ``begins-with "foo"'' should catch both rows, not just one.  As
whitespace isn't necessarily visible (consider a column where every cell starts
with a space), this won't drive users to madness. :-)
Comment 43 jpryor 2007-08-09 20:23:14 UTC
Created attachment 47446 [details]
Adds file format support to save the new filter settings into .ods files.
Comment 44 jpryor 2007-08-09 20:28:32 UTC
The sc-standard-filter-options-ods-hack.diff patch adds filter persistance
support in accordance with:

    http://lists.oasis-open.org/archives/office/200701/msg00020.html.

However, this support is currently a work-in-progress (hack!), as it requires
"working around" the com::sun::star::sheet::FilterOperator enum, as the enum
cannot be extended:

    http://sc.openoffice.org/servlets/ReadMsg?list=dev&msgNo=2471

Good news: the new filters can be saved with this patch.  Bad news: this isn't
really ready to go into HEAD.  A better fix will wait for Kohei's work on a
multi-selection filter selection:

    http://sc.openoffice.org/servlets/ReadMsg?list=dev&msgNo=2476
Comment 45 jpryor 2007-08-10 20:45:11 UTC
Created attachment 47473 [details]
Previous version had a compilation error (sorry).  This is the correct sc-standard-filter-options.diff patch.
Comment 46 jpryor 2007-08-10 21:03:37 UTC
For QA purposes, when filtering:

  Begins-With "foo" now matches " foo" (leading whitespace ignored)
  Ends-With "foo" now matches "foo " (trailing whitespace ignored)

When import/exporting Excel 97-2003 files,
begins-with/ends-with/contains/does-not-contain is preserved:

  Excel (begins-with "foo") maps to (Begins with "foo") (and vice versa)
  Excel (ends-with "foo") maps to (Ends with "foo") (and vice versa)
  Excel (contains "foo.") maps to (Contains "foo.") (and vice versa)
  Excel (does-not-contain "foo") maps to (Does not Contain "foo") (and vice versa)

Every Excel filter expression that contains a wildcard (*, ?) is mapped to a
Calc filter expression using regular expressions:

  Excel (contains "foo*bar") maps to (Contains "foo.*bar"), regex enabled.
  Excel (contains "foo?bar") maps to (Contains "foo.bar"), regex enabled.
  Excel (contains "*foo*") maps to (Contains ".*foo.*"), regex enabled.
  Excel (contains "*foo.") maps to (Contains ".*foo\."), regex enabled.

On export, only the regular expressions ".*" and "." are mapped to their
corresponding Excel wildcard expressions.  If a '\' (backslash) is found, it is
removed (leaving the "escaped character" behind).  Any other regular expression
is _not_ handled:

  Calc (Contains "foo[[:space:]]*bar\.") is exported as "contains
"foo[[:space:]]*bar." (and likely will be meaningless in Excel).

This allows full fidelity when importing and exporting to an existing Excel
spreadsheet as long as the filter expressions are not altered to use full
regular expressions.
Comment 47 ooo 2007-08-13 18:00:36 UTC
Hi Jonathan,

Thanks for the patch. I'd hesitate though to apply the patch as is. Please note
that for wildcards we have issue 32344, and the next version of the ODF spec
will include a table:use-wildcards attribute, see that issue. Note also that
Excel wildcards use the '~' tilde character as an escape character, which the
workaround conversion doesn't implement. Also a '\' backslash contained in the
Excel string and other regex meta characters are not escaped, so the conversion
would only partly work.


From a first glance it doesn't seem that IsMatch() works as it should,

+	BOOL bBegin = HasNonWSInRange(s, 0, nMatchStart);
+	BOOL bEnd   = HasNonWSInRange(s, nMatchEnd, s.Len());
+	if (bMatchWholeCell && (bBegin || bEnd))
+		return FALSE;

doesn't seem to act identical to the previous expression it replaces,

-                if ( bMatch && bMatchWholeCell
-						&& (nStart != 0 || nEnd != aCellStr.Len()) )

in case bMatchWholeCell==true and nStart>0 and some leading whitespace is
contained and an exact regex is to be matched, but maybe I just didn't dive deep
enough into the changes.

Btw, please make your editor use blanks instead of tabs when indenting, with a
shift width of 4 spaces per indent level.

Thanks
  Eike
Comment 48 jpryor 2007-08-13 18:36:38 UTC
bMatchWholeCell used to mean equality, hence the `(nStart != 0 || nEnd !=
aCellStr.Len())` check ("matched string must start at index 0 and end at
aCellStr.Len()").

I've changed this to ignore leading/trailing whitespace.

So if bMatchWholeCell == true and nStart > 0, but aCellStr[0..nStart] is only
whitespace, it *should* match (thus it ignores leading whitespace).  Ditto for
aCellStr[nEnd..aCellStr.Len()-1].

So it is NOT identical to previous behavior, deliberately so, as
leading/trailing whitespace is ignored.

If you really want/need an exact match, using ^ and $ in your regex (to match
start/end of the string).  The regex is performed before the leading/trailing
whitespace is ignored.

Example: Column data (without quotes)

  "foo"
  " foo"
  " foo "

Before, a regex of "Equals foo" would only match the first row.  After my
change, it will match all three rows.

Before and after, a regex of "Equals ^foo$" will only match the first row.  If
you need a regex using ^/$ to match the other rows, you'll need to explicitly
permit spaces, e.g. "Equals ^[[:space:]]*foo[[:space:]]*$".

I will look into issue 32344 and the '~' escape semantics.
Comment 49 ooo 2007-08-14 11:52:01 UTC
>   "foo"
>   " foo"
>   " foo "
> 
> Before, a regex of "Equals foo" would only match the first row.  After my
> change, it will match all three rows.

That should be avoided. Note that ScTable::ValidQuery() is also used by
formula functions, so loading a document suddenly and silently may
produce different results.
Comment 50 thomas.benisch 2007-12-19 09:12:23 UTC
cc tbe
Comment 51 gaozm 2008-01-07 03:10:16 UTC
Created attachment 50685 [details]
Add some filter-conditions and change the layout to the new  dialog style by shifting OK/Cancel/Help buttons
Comment 52 lvyue 2008-01-07 05:20:16 UTC
Created attachment 50691 [details]
A patch
Comment 53 thomas.benisch 2008-01-07 16:28:47 UTC
This iteration of the patch is much better. Please see my comments below.

Thomas


================================================================================
The code for exporting/importing the new filter conditions to/from ODF is
missing!!!
================================================================================

I got the news from Eike, that the missing '!begins' and '!ends'
attribute values were proposed to the OASIS ODF TC today. Probably next week
they will decide about them.

================================================================================
sc/source/core/data/table3.cxx
================================================================================

@@ -1036,29 +1043,45 @@ BOOL ScTable::ValidQuery(SCROW nRow, con
             else
                 GetInputString( static_cast<SCCOL>(rEntry.nField), nRow,
aCellStr );
 
-            BOOL bRealRegExp = (rParam.bRegExp && ((rEntry.eOp == SC_EQUAL)
-                || (rEntry.eOp == SC_NOT_EQUAL)));
+            BOOL bRealRegExp = (rParam.bRegExp && ((rEntry.eOp == SC_EQUAL)   
            
+			|| (rEntry.eOp == SC_NOT_EQUAL) || (rEntry.eOp == SC_CONTAINS) 

+				|| (rEntry.eOp == SC_DOES_NOT_CONTAIN) || (rEntry.eOp == SC_BEGINS_WITH)

+				|| (rEntry.eOp == SC_ENDS_WITH) || (rEntry.eOp == SC_DOES_NOT_BEGIN_WITH)

+                || (rEntry.eOp == SC_DOES_NOT_END_WITH)));

             BOOL bTestRegExp = (pbTestEqualCondition && rParam.bRegExp
                 && ((rEntry.eOp == SC_LESS_EQUAL)
                     || (rEntry.eOp == SC_GREATER_EQUAL)));
             if ( bRealRegExp || bTestRegExp )
             {
-				xub_StrLen nStart = 0;
+                xub_StrLen nStart = (rEntry.eOp == SC_ENDS_WITH 
+                    || rEntry.eOp == SC_DOES_NOT_END_WITH)? ( aCellStr.Len() -
rEntry.pStr->Len() ):0;
 				xub_StrLen nEnd   = aCellStr.Len();
                 BOOL bMatch = (BOOL) rEntry.GetSearchTextPtr( rParam.bCaseSens )
 					->SearchFrwrd( aCellStr, &nStart, &nEnd );

The code branch for searching with regular expressions needs some rework.
Thanks to Eike for all the hints.
For the SC_ENDS_WITH and SC_DOES_NOT_END_WITH part,
setting nStart to aCellStr.Len() - rEntry.pStr->Len() is not correct, as your
regular expression can match the whole cell string, although the length of
the regular expression is much shorter. Therefore you have to search starting
with nStart=0, that means the whole cell string. You'll get some problems, if
the cell string contains the regular expression more than one time, therefore
you have to guarantee, that you find the last occurance. Probably
TextSearch::SearchBkwrd() is your friend in this case.
Finally you can check, if nEnd equals aCellStr.Len().

-                if ( bMatch && bMatchWholeCell
-						&& (nStart != 0 || nEnd != aCellStr.Len()) )
-                    bMatch = FALSE;    // RegExp must match entire cell string
+                if ( bMatch )
+                {
+                    if ( bMatchWholeCell && (nStart != 0 || nEnd !=
aCellStr.Len()) )
+                        bMatch = FALSE;
+                    else if ( ((rEntry.eOp == SC_BEGINS_WITH || rEntry.eOp ==
SC_DOES_NOT_BEGIN_WITH)
+                                && (nStart != 0))
+                           || ((rEntry.eOp == SC_ENDS_WITH || rEntry.eOp ==
SC_DOES_NOT_END_WITH)
+                                && (nEnd != aCellStr.Len())) )
+                        bMatch = FALSE;
+                }
                 if ( bRealRegExp )
-                    bOk = ((rEntry.eOp == SC_NOT_EQUAL) ? !bMatch : bMatch);
+                    bOk = ((rEntry.eOp == SC_NOT_EQUAL || rEntry.eOp ==
SC_DOES_NOT_CONTAIN
+                            || rEntry.eOp == SC_DOES_NOT_BEGIN_WITH 
+                            || rEntry.eOp == SC_DOES_NOT_END_WITH) ? !bMatch :
bMatch);

This part of the code is hard to read and hard to understand,
especially bOK = !bMatch a few lines later. I would recommend to have a switch
statement and handle there the different cases for SC_BEGINS_WITH,
SC_DOES_NOT_BEGIN_WITH, etc.

@@ -1078,10 +1101,35 @@ BOOL ScTable::ValidQuery(SCROW nRow, con
                         String aQuer( pTransliteration->transliterate(
                             *rEntry.pStr, ScGlobal::eLnge, 0, rEntry.pStr->Len(),
                             &xOff ) );
-                        bOk = (aCell.Search( aQuer ) != STRING_NOTFOUND);
+                        xub_StrLen nIndex = (rEntry.eOp == SC_ENDS_WITH 
+                            || rEntry.eOp == SC_DOES_NOT_END_WITH)?
(aCell.Len()-aQuer.Len()):0;
+                        xub_StrLen nStrPos = aCell.Search( aQuer, nIndex );
+                        switch (rEntry.eOp)
+                        {
+                        case SC_EQUAL:
+                        case SC_CONTAINS:
+                        case SC_NOT_EQUAL:
+                        case SC_DOES_NOT_CONTAIN:
+                            bOk = ( nStrPos != STRING_NOTFOUND );
+                            break;
+                        case SC_BEGINS_WITH :
+                        case SC_DOES_NOT_BEGIN_WITH :
+                            bOk = ( nStrPos == 0 );
+                            break;
+                        case SC_ENDS_WITH :
+                        case SC_DOES_NOT_END_WITH :
+                            bOk = ( nStrPos + aQuer.Len() == aCell.Len() );
+                            break;
+                        default:
+                            {
+                                // added to avoid warnings
+                            }
+                        }
 					}
-					if ( rEntry.eOp == SC_NOT_EQUAL )
-						bOk = !bOk;
+                    if ( rEntry.eOp == SC_NOT_EQUAL || rEntry.eOp ==
SC_DOES_NOT_CONTAIN
+                        || rEntry.eOp == SC_DOES_NOT_BEGIN_WITH 
+                        || rEntry.eOp == SC_DOES_NOT_END_WITH )
+                        bOk = !bOk;

The code branch for searching without regular expressions is in general fine.
Nevertheless I would also recommend to move the bOk = !bOk part to the
case statements, e.g.

                        case SC_BEGINS_WITH :
                            bOk = ( nStrPos == 0 );
                            break;
                        case SC_DOES_NOT_BEGIN_WITH :
                            bOk = ( nStrPos != 0 );
                            break;


================================================================================
sc/source/ui/inc/filtdlg.hxx
================================================================================

@@ -103,6 +103,7 @@ ScFilterDlg::ScFilterDlg( SfxBindings* p
 		aFtField		( this, ScResId( FT_FIELD ) ),
 		aFtCond			( this, ScResId( FT_COND ) ),
 		aFtVal			( this, ScResId( FT_VAL ) ),
+    aFlSeparator     ( this, ScResId( FL_SEPARATOR ) ),

Please indent with 8 spaces.

================================================================================
sc/source/ui/inc/filtdlg.hxx
================================================================================

@@ -154,6 +154,7 @@ private:
 	FixedText		aFtField;
 	FixedText		aFtCond;
 	FixedText		aFtVal;
+  FixedLine       aFlSeparator;

Please indent with 4 spaces.

================================================================================
sc/source/ui/src/filter.src
================================================================================

Please align the 'Copy results to ...' list boxes and the Shrink button
(Options section) on the right edge with the Help button. See Franks mockup
(http://wiki.services.openoffice.org/wiki/Image:Standard_Filter_Dialog.png)
for more details.

@@ -58,13 +58,13 @@ ModelessDialog RID_SCDLG_FILTER
 	FixedText FT_COND
 	{
         Pos = MAP_APPFONT ( 122 , 14 ) ;
-        Size = MAP_APPFONT ( 47 , 8 ) ;
+        Size = MAP_APPFONT ( 75 , 8 ) ;
 		Text [ en-US ] = "Condition" ;
 	};
 	FixedText FT_VAL
 	{
-        Pos = MAP_APPFONT ( 173 , 14 ) ;
-        Size = MAP_APPFONT ( 60 , 8 ) ;
+    Pos = MAP_APPFONT ( 201 , 14 ) ;
+    Size = MAP_APPFONT ( 60 , 8 ) ;

Please indent with 8 spaces.

@@ -178,25 +190,31 @@ ModelessDialog RID_SCDLG_FILTER
 			< "Smallest" ; Default ; > ;
 			< "Largest %" ; Default ; > ;
 			< "Smallest %" ; Default ; > ;
+			< "Contains" ; Default ; > ;
+			< "Does not contain" ; Default ; > ;
+			< "Begins with" ; Default ; > ;
+			< "Does not begin with" ; Default ; > ;
+			< "Ends with" ; Default ; > ;
+			< "Does not end with" ; Default ; > ;
 		};
 	};
 	ComboBox ED_VAL1
 	{
-        Pos = MAP_APPFONT ( 173 , 25 ) ;
+		Pos = MAP_APPFONT ( 201 , 25 ) ;
 		Size = MAP_APPFONT ( 60 , 90 ) ;
 		TabStop = TRUE ;
 		DropDown = TRUE ;
 	};
 	ComboBox ED_VAL2
 	{
-        Pos = MAP_APPFONT ( 173 , 41 ) ;
+    Pos = MAP_APPFONT ( 201 , 41 ) ;

Please indent with 8 spaces.

 	ComboBox ED_VAL3
 	{
-        Pos = MAP_APPFONT ( 173 , 57 ) ;
+    Pos = MAP_APPFONT ( 201 , 57 ) ;

Please indent with 8 spaces.

@@ -204,13 +222,13 @@ ModelessDialog RID_SCDLG_FILTER
     FixedLine FL_CRITERIA
 	{
 		Pos = MAP_APPFONT ( 6 , 3 ) ;
-        Size = MAP_APPFONT ( 230 , 8 ) ;
+    Size = MAP_APPFONT ( 258 , 8 ) ;

Please indent with 8 spaces.
Comment 54 thomas.benisch 2008-01-09 09:52:41 UTC
gaozm:
I would use the following strategy for finding the right
code places for the XML import/export.
Set up a standard filter with condition '=' and check
that this condition is exported and imported again
while saving/loading.
Set a breakpoint in all locations where SC_EQUAL is
checked.
Each breakpoint which is hit during saving/loading
is a location where you have to add your new filter
conditions.

In addition, as already said, you probably have to
also add the new attribute values in xmloff.
Comment 55 lvyue 2008-01-10 04:26:31 UTC
Created attachment 50776 [details]
I have modified the last patch according to tbe's comments. Please check it. And for the ODF part, we stiil need some time.
Comment 56 gaozm 2008-01-10 05:18:43 UTC
Hello tbe:
    That's a good idear. Following your idear, I will do it right now. And give
you  a feedback as soon as possible. Thank you.
  
Comment 57 thomas.benisch 2008-01-11 10:03:45 UTC
lvyue:
Apart from the missing ODF code I have only one consolidation issue.


================================================================================
sc/source/core/data/table3.cxx
================================================================================

@@ -1045,14 +1055,51 @@ BOOL ScTable::ValidQuery(SCROW nRow, con
             {
                 xub_StrLen nStart = 0;
                 xub_StrLen nEnd   = aCellStr.Len();
-                BOOL bMatch = (BOOL) rEntry.GetSearchTextPtr( rParam.bCaseSens )
-                    ->SearchFrwrd( aCellStr, &nStart, &nEnd );
                 // from 614 on, nEnd is behind the found text
+                BOOL bMatch = FALSE;
+                if ( rEntry.eOp == SC_ENDS_WITH || rEntry.eOp ==
SC_DOES_NOT_END_WITH )
+                {
+                    nEnd = 0;
+                    nStart = aCellStr.Len();
+                    bMatch = (BOOL) rEntry.GetSearchTextPtr( rParam.bCaseSens )
+                        ->SearchBkwrd( aCellStr, &nStart, &nEnd );
+                } 
+                else
+                {
+                    bMatch = (BOOL) rEntry.GetSearchTextPtr( rParam.bCaseSens )
+                        ->SearchFrwrd( aCellStr, &nStart, &nEnd );
+                }
                 if ( bMatch && bMatchWholeCell
                         && (nStart != 0 || nEnd != aCellStr.Len()) )
                     bMatch = FALSE;    // RegExp must match entire cell string
                 if ( bRealRegExp )
-                    bOk = ((rEntry.eOp == SC_NOT_EQUAL) ? !bMatch : bMatch);
+                    switch (rEntry.eOp)
+                    {
+                    case SC_EQUAL:
+                    case SC_CONTAINS:
+                        bOk = bMatch;
+                        break;
+                    case SC_NOT_EQUAL:
+                    case SC_DOES_NOT_CONTAIN:
+                        bOk = !bMatch;
+                        break;
+                    case SC_BEGINS_WITH:
+                        bOk = ( bMatch && (nStart == 0) );
+                        break;
+                    case SC_DOES_NOT_BEGIN_WITH:
+                        bOk = !( bMatch && (nStart == 0) );
+                        break;
+                    case SC_ENDS_WITH:
+                        bOk = ( bMatch && (nEnd == aCellStr.Len()) );
+                        break;
+                    case SC_DOES_NOT_END_WITH:
+                        bOk = !( bMatch && (nEnd == aCellStr.Len()) );
+                        break;
+                    default:
+                        {
+                            // added to avoid warnings
+                        }
+                    }

This is really nice code, that's exactly what I meant.

@@ -1083,6 +1130,46 @@ BOOL ScTable::ValidQuery(SCROW nRow, con
                     if ( rEntry.eOp == SC_NOT_EQUAL )
                         bOk = !bOk;
                 }
+                else if( rEntry.eOp == SC_CONTAINS || rEntry.eOp ==
SC_DOES_NOT_CONTAIN
+                    || rEntry.eOp == SC_BEGINS_WITH || rEntry.eOp == SC_ENDS_WITH
+                    || rEntry.eOp == SC_DOES_NOT_BEGIN_WITH || rEntry.eOp ==
SC_DOES_NOT_END_WITH )
+                {
+                    ::com::sun::star::uno::Sequence< sal_Int32 > xOff;
+                    String aCell( pTransliteration->transliterate(
+                        aCellStr, ScGlobal::eLnge, 0, aCellStr.Len(),
+                        &xOff ) );
+                    String aQuer( pTransliteration->transliterate(
+                        *rEntry.pStr, ScGlobal::eLnge, 0, rEntry.pStr->Len(),
+                        &xOff ) );
+                    xub_StrLen nIndex = (rEntry.eOp == SC_ENDS_WITH 
+                        || rEntry.eOp == SC_DOES_NOT_END_WITH)?
(aCell.Len()-aQuer.Len()):0;
+                    xub_StrLen nStrPos = aCell.Search( aQuer, nIndex );
+                    switch (rEntry.eOp)
+                    {
+                    case SC_CONTAINS:
+                        bOk = ( nStrPos != STRING_NOTFOUND );
+                        break;
+                    case SC_DOES_NOT_CONTAIN:
+                        bOk = ( nStrPos == STRING_NOTFOUND );
+                        break;
+                    case SC_BEGINS_WITH:
+                        bOk = ( nStrPos == 0 );
+                        break;
+                    case SC_DOES_NOT_BEGIN_WITH:
+                        bOk = ( nStrPos != 0 );
+                        break;
+                    case SC_ENDS_WITH:
+                        bOk = ( nStrPos + aQuer.Len() == aCell.Len() );
+                        break;
+                    case SC_DOES_NOT_END_WITH:
+                        bOk = ( nStrPos + aQuer.Len() != aCell.Len() );
+                        break;
+                    default:
+                        {
+                            // added to avoid warnings
+                        }
+                    }
+                }

Also that's what I meant, but I think you can further consolidate code by
combining the SC_EQUAL ... code branch and the SC_CONTAINS ... code branch.
Comment 58 gaozm 2008-01-17 07:52:17 UTC
Created attachment 50931 [details]
I have extended the UNO API
Comment 59 gaozm 2008-01-17 07:54:30 UTC
Created attachment 50932 [details]
I have extended the UNO API
Comment 60 gaozm 2008-01-17 07:55:26 UTC
Created attachment 50933 [details]
I have extended the UNO API
Comment 61 lvyue 2008-01-17 08:01:55 UTC
Created attachment 50934 [details]
patch2
Comment 62 thomas.benisch 2008-01-17 09:32:59 UTC
TBE->GAOZM:

================================================================================
FilterOperator2.idl
================================================================================

Please use spaces instead of tabs for indentation.

> module com {  module sun {  module star {  module sheet {

Please add a comment here. It also makes sense to explain, why FilterOperator2
was introduced (additional filter operators).

>
> 	constants FilterOperator2

I think you can already use published here.

> 	//-------------------------------------------------------------------------
>
>      /** selects begins-with entries.
>      */
> 	 const long BEGINS_WITH = 14;

Please indent as follows:

    /** selects begins-with entries.
     */


================================================================================
TableFilterField2.idl
================================================================================

Please use spaces instead of tabs for indentation.

> module com {  module sun {  module star {  module sheet {

Please add a comment here. It also makes sense to explain the difference to
TableFilterField.

>
> struct TableFilterField2

I think you can already use published here.

> 	//-------------------------------------------------------------------------
>
>	/** specifies the type of the condition.
> 	 */
>	long Operator;

Please note in the comment, that type FilterOperator2 is used here.

>	/** selects whether the <member>TableFilterField::NumericValue</member>
>		or the <member>TableFilterField::StringValue</member> is used.
>	 */
>	boolean IsNumeric;

Please exchange TableFilterField with TableFilterField2 here.


================================================================================
XSheetFilterDescriptor2.idl
================================================================================

Please use spaces instead of tabs for indentation.

>module com {  module sun {  module star {  module sheet {

Please add a comment here. It also makes sense to explain the difference to
XSheetFilterDescriptor.

>	published interface XSheetFilterDescriptor2: com::sun::star::uno::XInterface

You cannot use getFilterFields() and setFilterFields() as method names here,
because this leads to problems when implementing this interface at the same
C++ object which implements XSheetFilterDescriptor. Also for Basic macros this
gives some problems. Therefore please use other names.
Comment 63 thomas.benisch 2008-01-17 09:35:40 UTC
TBE->LVYUE:
This patch is fine. Thanks for all this work.
Comment 64 gaozm 2008-01-18 04:46:04 UTC
Created attachment 50950 [details]
Extend the UNO API
Comment 65 gaozm 2008-01-18 04:47:27 UTC
Created attachment 50951 [details]
Extend the UNO API
Comment 66 gaozm 2008-01-18 04:48:33 UTC
Created attachment 50952 [details]
Extend the UNO API
Comment 67 thomas.benisch 2008-01-18 09:44:50 UTC
TBE->GAOZM:

Please see my comments below. 


================================================================================
FilterOperator2.idl
================================================================================

> /** FilterOperator2 was introduced in order to add additional filter operators
> */

better:

/** specifies the type of a single condition in a filter descriptor.

    <p>This constants group extends the <type>FilterOperator</type> enum by
    additional filter operators.</p>

    @since OOo 3.0
 */


================================================================================
TableFilterField2.idl
================================================================================

> /** FilterOperator2 is a member of TableFilterField2
> */

better:

/** describes a single condition in a filter descriptor.

   <p>This struct has the <type>FilterOperator2</type> constants group as
   member, whereas the <type>TableFilterField</type> struct uses the
   <type>FilterOperator</type> enum.</p>

    @see com::sun::star::sheet::SheetFilterDescriptor

    @since OOo 3.0
 */

>     /** specifies the type of the condition. And the type FilterOperator2 is
used here.
>      */

better:

/** specifies the type of the condition as defined in <type>FilterOperator2</type>.
 */


================================================================================
XSheetFilterDescriptor2.idl
================================================================================

> /**XSheetFilterDescriptor2 is derived from XSheetFilterDescriptor.
> */

That's not the case, it's derived from XInterface.

better:

/** provides access to a collection of filter conditions (filter fields).

    <p>This interface uses the <type>TableFilterField2</type> struct, whereas the
    <type>XSheetFilterDescriptor</type> interface uses the
    <type>TableFilterField</type> struct.</p>

    @see com::sun::star::sheet::SheetFilterDescriptor

    @since OOo 3.0
 */
Comment 68 gaozm 2008-01-29 08:23:36 UTC
Created attachment 51221 [details]
A patch about the XML import/export
Comment 69 thomas.benisch 2008-01-29 10:00:38 UTC
TBE->GAOZM:

Hi Gao,

each patch review includes applying the patch, compiling the
modules and testing. Therefore can you please provide a
patch which

a) includes all the IDL files
b) includes the corresponding makefile entries
c) has the full file path for each file, e.g.
   sc/source/ui/unoobj/datauno.cxx instead of sc/datauno.cxx

All this is needed anyway and would save me lots of manual
work.

Thanks,

Thomas
Comment 70 branday 2008-01-30 07:30:02 UTC
Extend filter.
Comment 71 gaozm 2008-01-30 07:53:44 UTC
Created attachment 51242 [details]
A new patch about the XML import/export (1)
Comment 72 gaozm 2008-01-30 07:55:04 UTC
Created attachment 51243 [details]
A new patch about the XML import/export (2)
Comment 73 gaozm 2008-01-30 07:56:29 UTC
Created attachment 51244 [details]
A new patch about the XML import/export (3)
Comment 74 gaozm 2008-01-30 07:58:33 UTC
Created attachment 51245 [details]
A new patch about the XML import/export (4)
Comment 75 gaozm 2008-01-31 08:19:55 UTC
Created attachment 51283 [details]
A patch about the XML import/export (offapi)
Comment 76 gaozm 2008-01-31 08:22:17 UTC
Created attachment 51284 [details]
A patch about the XML import/export (sc)
Comment 77 thomas.benisch 2008-02-08 16:09:45 UTC
TBE->GAOZM:

Please see my comments on offapi.patch below.


================================================================================
TableFilterField2.idl
================================================================================

+   <p>This struct has the <type>FilterOperator2</type> constants group as
+   member, whereas the <type>TableFilterField</type> struct uses the
+   <type>FilterOperator</type> enum.</p>

Please indent by one more space.

+published struct TableFilterField2
+{
+		//-------------------------------------------------------------------------
+

Please don't use tabs, but spaces.

+	/** specifies the type of the condition as defined in
<type>FilterOperator2</type>.
+     */
+	long Operator;

Please restrict to 80 chars per line.


================================================================================
TableFilterField2.idl
================================================================================

+    <p>This interface uses the <type>TableFilterField2</type> struct, whereas the
+    <type>XSheetFilterDescriptor</type> interface uses the
+    <type>TableFilterField</type> struct.</p>

Please restrict to 80 chars per line.


================================================================================
makefile.mk
================================================================================

hunk 1 and 3 fail for SRC680 m245
Comment 78 thomas.benisch 2008-02-08 16:13:05 UTC
TBE->GAOZM:

sc.patch doesn't compile. There are several undeclared indentifiers:
XML_CONTAINS, XML_DOES_NOT_CONTAIN, etc.
Comment 79 gaozm 2008-02-18 08:31:58 UTC
Created attachment 51558 [details]
A patch about the XML import/export (offapi) (1)
Comment 80 gaozm 2008-02-18 08:33:22 UTC
Created attachment 51559 [details]
A patch about the XML import/export (sc) (1)
Comment 81 gaozm 2008-02-18 08:35:21 UTC
Created attachment 51560 [details]
A patch about the XML import/export (xmloff) (1)
Comment 82 gaozm 2008-02-19 08:09:09 UTC
Created attachment 51584 [details]
A new patch. the patch to the XML import/export (xmloff) (1) above is wrong.
Comment 83 gaozm 2008-02-25 02:59:08 UTC
Created attachment 51696 [details]
A new patch. the patch to the XML import/export (xmloff) above is wrong
Comment 84 gaozm 2008-03-11 09:41:57 UTC
Created attachment 52020 [details]
Another patch about the XML import/export (sc)
Comment 85 gaozm 2008-03-11 09:43:13 UTC
Created attachment 52021 [details]
Another patch about the XML import/export (offapi)
Comment 86 thomas.benisch 2008-03-11 11:13:33 UTC
TBE->GAOZM:

offapi.patch from Feb 18, 2008:
------------------------------

This patch is fine.


xmloff.patch from Feb 25, 2008:
------------------------------

Two hunks fail for SRC680 m245. Probably it makes sense to adjust
your patches for DEV300. In addition, please use spaces instead
of tabs. Otherwise this patch is fine.


offapi(1).patch and sc(1).patch from Mar 11, 2008:
-------------------------------------------------

I think that's exactly the wrong approach and not the way we
discussed in our last IRC meeting.

You basically added the interfaces XDatabaseRange2, XSheetFilterable2
and XSheetFilterableEx2. In the sc module you replaced in some
locations the existing interfaces XDatabaseRange, XSheetFilterable
and XSheetFilterableEx by the new ones. This approach has the
disadvantage, that the extension of the UNO API is unnecessary
and more worse, that you break existing functionality.

Therefore I propose the following approach:
The ScFilterDescriptorBase object and all derived objects support
XSheetFilterDescriptor and XSheetFilterDescriptor2.
If a method, e.g. ScXMLExportDatabaseRanges::WriteFilterDescriptor()
has a parameter 
const uno::Reference <sheet::XSheetFilterDescriptor>& xSheetFilterDescriptor,
then you can query the xSheetFilterDescriptor object for the
XSheetFilterDescriptor2 interface. If this query is successful, then you
call the methods of XSheetFilterDescriptor2, otherwise you call the
methods of XSheetFilterDescriptor. Please see some pseudo code below.

Reference< XSheetFilterDescriptor2 > xDesc2( xSheetFilterDescriptor, UNO_QUERY );
if ( xDesc2.is() )
{
    Sequence< TableFilterField2 > aTableFilterFields2(
xDesc2->getFilterFields2() );   
}
else
{
    Sequence< TableFilterField > aTableFilterFields(
xSheetFilterDescriptor->getFilterFields() );
}
Comment 87 gaozm 2008-03-13 06:51:51 UTC
Created attachment 52067 [details]
What about this patch about the function ScXMLExportDatabaseRanges::WriteFilterDescriptor()?
Comment 88 thomas.benisch 2008-03-14 09:06:41 UTC
Hi Gao,

your 1.patch from Mar 13, 2008 is the right approach. You can even
think about adding a method

  void ScXMLExportDatabaseRanges::WriteFilterDescriptor(
    const Reference<XSheetFilterDescriptor2>& xSheetFilterDescriptor2,
    const ::rtl::OUString sDatabaseRangeName)

and query for XSheetFilterDescriptor2 before calling WriteFilterDescriptor().
But that's just a matter of taste.

In addition you also produced lots of similar/duplicate code, e.g. the first
part of the WriteFilterDescriptor() implementation. Probably you have an
idea of how to consolidate the code.

Thomas
Comment 89 gaozm 2008-03-18 09:36:32 UTC
Created attachment 52183 [details]
A patch about the XML import/export。
Comment 90 thomas.benisch 2008-03-26 18:08:05 UTC
Hi Gao,

I tried to apply your sc(2).patch from Mar 18, 2008, but the patch
fails for sc/source/ui/vba/vbarange.cxx:

Hunk #1 FAILED at 105.
Hunk #2 FAILED at 3324.

It also seems, that the corresponding code in ScVbaRange::AutoFilter() has
changed, please check.

As this part of the patch should only affect VBA specifics, I tested
your patch. If I create a standard filter with the new filter conditions
it seems, that the new conditions are not saved to the xml file.
In addition, I get the assertion "Falscher Filter-enum" from
ScFilterDescriptorBase::getFilterFields() or
ScFilterDescriptorBase::getFilterFields2().
Do you observe the same problem?

Before you submit the next iteration of your patch it would be nice,
if you combine all your sc patches into one patch, because due to
the amount of patches it gets more and more difficult for me to
keep track of all the patches. In addition it would make sense
to refer to the latest DEV300 milestone.

Thomas
Comment 91 gaozm 2008-04-30 05:35:42 UTC
Created attachment 53273 [details]
A patch about issue 35579
Comment 92 gaozm 2008-05-06 04:43:25 UTC
Created attachment 53402 [details]
A patch about vbarange.cxx
Comment 93 thomas.benisch 2008-05-06 11:14:05 UTC
Hi Gao,

I applied your patch from April 20, 2008 to a DEV300 m10 milestone.
Some hunks failed, but those needed some minor modifications only.
Also in this milestone I couldn't reproduce your crashes.
The export of the new filter conditions works fine, but the import
doesn't work. I debugged your code with the result that
the aFilterFields2 member in ScXMLDatabaseRangeContext is empty.
This sequence must be filled during the import.

Therefore I propose the following steps:

1. Extend the ScXMLFilterContext class by a
   Sequence< sheet::TableFilterField2 > member and a
   void AddFilterField2( const sheet::TableFilterField2 aFilterField2 )
   method. This method must be called in
   ScXMLConditionContext::EndElement() (*).

2. Add a
   void SetFilterFields2( const Sequence< sheet::TableFilterField2>& )
   method to the ScXMLDatabaseRangeContext class. This method must be
   called in ScXMLFilterContext::EndElement() (*).

(*) Probably you find a way to call those methods only, if the
    XSheetFilterDescriptor2 interface is supported.

Thomas
Comment 94 thomas.benisch 2008-05-06 11:59:13 UTC
Hi Gao,

I had a look at your patch from May 6, 2008 and I was really
wondering, why you assign to the Operator member of the
TableFilterField2 struct values of type FilterOperator
instead of FilterOperator2.

Thomas
Comment 95 gaozm 2008-05-07 08:30:03 UTC
Created attachment 53436 [details]
A new patch about the file vbarange.cxx
Comment 96 gaozm 2008-05-08 07:25:14 UTC
Hi, Thomas
    What about the last patch about the file vbarange.cxx?
Comment 97 gaozm 2008-05-12 04:53:02 UTC
Created attachment 53557 [details]
A new patch about issue 35579.
Comment 98 thomas.benisch 2008-05-14 15:55:32 UTC
Hi Gao,

I tested your latest patch from May 12, 2008 and found a
problem.

I create a standard filter on a table and set the 'contains'
condition and a value of e.g. 'blue'. Then I save and close the
document. After that I open the document again. Now the problem
is, that the  Standard Filter dialog doesn't show the 'contains'
condition, but the '=' condition and a value of '- empty -'.

Can you please debug and fix this problem. And please test your
patches before attaching them for review. For me it's always
very time consuming to apply the patch and build the
corresponding projects. 

Thomas
Comment 99 gaozm 2008-05-15 09:49:03 UTC
Hello Thomas:
    Thank your for your comments. After testing, I found that the problem
happened during the export course. I will trace it, in the meanwhile, I hope you
offer me some help.

gaozm
Comment 100 frank.loehmann 2008-05-22 09:33:34 UTC
This issue is important and listed on the quarterly review for Calc:
http://wiki.services.openoffice.org/wiki/2008_Q2_Review_of_Spreadsheet_Project
Therefore adjusting target to 3.x.
Comment 101 ooo 2008-05-29 18:45:05 UTC
*** Issue 89549 has been marked as a duplicate of this issue. ***
Comment 102 gaozm 2008-06-12 09:19:43 UTC
Created attachment 54418 [details]
A complete patch to issue 35579.
Comment 103 frank 2008-07-09 08:39:23 UTC
*** Issue 90605 has been marked as a duplicate of this issue. ***
Comment 104 tuharsky 2008-07-09 08:49:09 UTC
The Ubuntu distributionl OpenOffice 2.4 does contain the filters, OxygenOffice
too. How is it possible, since this issue is targeted at 3.x? Do they apply the
patch? As listed in Issue 90605 (a duplicate)...
Comment 105 ooo 2008-07-10 14:12:18 UTC
@tuharsky: apparently they apply some go-oo patch; whatever patch that may be,
most certainly not the one under discussion here.
Comment 106 gaozm 2008-07-14 03:15:21 UTC
Hi,all
    Could you review the last patch? Thank you.
Comment 107 amy2008 2008-09-25 08:36:40 UTC
*** Issue 84874 has been marked as a duplicate of this issue. ***
Comment 108 canis 2008-11-30 09:19:07 UTC
> Additional comments from gaozm Mon Jul 14 02:15:21 +0000 2008 -------
> Could you review the last patch?

Nobody can???
Comment 109 renatoyamane 2008-12-01 10:12:50 UTC
@canis,
Maybe not, because:

1) A lot of people here are *users* and not *developers*.
2) Apply a patch and compile OOo is not easy to them.
3) And maybe, all this users are using Go-oo, wich contain a similar (or the
same) patch to do this a long time ago.

Best regards,
Renato
Comment 110 canis 2008-12-02 04:52:49 UTC
As a *user* who wants to use native OOo, I asked for *developers* who can *аpply
a patch and compile OOo*.
Comment 111 gaozm 2008-12-03 01:23:58 UTC
The last patch based on DEV300_m2.
Comment 112 prabinrng 2009-02-24 09:58:26 UTC
Please add , contains , start with , end with in the filter option
Comment 113 prabinrng 2009-02-24 09:58:37 UTC
Please add , contains , start with , end with in the filter option
Comment 114 globetrot 2009-02-24 10:33:21 UTC
I notice there's a patch file available here, but don't find it included in any
build.  Is there an easy way for a newbie to include this functionality in OOo
3.0.1?
Comment 115 thomas.benisch 2009-02-25 09:52:02 UTC
TBE->GLOBETROT:
The patch is not finished yet. Therefore I don't recommend to include
this patch in its current state in any code line. There's also no
easy way for a newbie to include this patch, you have to build several
projects and register the new UNO types.
Comment 116 renatoyamane 2009-02-25 13:06:36 UTC
@prabinrng: If need this options, install Go-oo (www.go-oo.org).
It already have all this options in more than 1 year ago.

Regards,
Renato
Comment 117 ooo 2009-03-12 18:11:31 UTC
*** Issue 90923 has been marked as a duplicate of this issue. ***
Comment 118 yonggang.mao 2009-03-25 09:38:34 UTC
Created attachment 61169 [details]
Update the patch.
Comment 119 thomas.benisch 2009-04-07 11:56:02 UTC
maoyg: On which milestone is your patch from March 25, 2009 based on?
Comment 120 yonggang.mao 2009-04-07 14:52:49 UTC
tbe:I used OOoDev300_m42 code.
Comment 121 thomas.benisch 2009-05-06 08:30:23 UTC
TBE->LVYUE,MAOYG:

This patch looks really nice. I did some testing and everything works fine.
I only have some minor remarks to your code, please see below.

Before we can integrate your patch we unfortunately have to wait until the
childworkspace (CWS) calc49 is integrated, because this CWS also changes
the filter dialog. After that it's necessary that you adjust your patch,
that means that you remove the duplicate and conflicting changes to the
filter dialog from your patch.

After the CWS calc49 is integrated it's also necessary that you update
the specification for this feature with the new screenshots
(FilterFeatureSpecificationDocument.odt, see attachment from
January 7, 2008).

Finally some code has to be written for the OOXML filter,
but I propose that this will be done by Daniel.


================================================================================
offapi/com/sun/star/sheet/FilterOperator2.idl
================================================================================

> +/** specifies the type of a single condition in a filter descriptor.
> +    <p>This constants group extends the <type>FilterOperator</type> enum by
> +    additional filter operators.</p>
> +    @since OOo 3.0
> +    */

For readability please add an empty line before and after the paragraph
starting with <p> and ending with </p>. Please update the @since tag
to OOo 3.2. And in addition please indent the end of the comment '*/'
as in all other lines. 

================================================================================
offapi/com/sun/star/sheet/TableFilterField2.idl
================================================================================

> +/** describes a single condition in a filter descriptor.
> +    <p>This struct has the <type>FilterOperator2</type> constants group as
> +    member, whereas the <type>TableFilterField</type> struct uses the
> +    <type>FilterOperator</type> enum.</p>
> +    @see com::sun::star::sheet::SheetFilterDescriptor
> +    @since OOo 3.0
> +    */

As in the previous comment please add some empty lines and change the
position of the '*/'. Please update the @since tag to OOo 3.2.

================================================================================
offapi/com/sun/star/sheet/XSheetFilterDescriptor2.idl
================================================================================

> +/** provides access to a collection of filter conditions (filter fields).
> +<p>This interface uses the <type>TableFilterField2</type> struct,
> +    whereas the <type>XSheetFilterDescriptor</type> interface uses the
> +    <type>TableFilterField</type> struct.</p>
> +    @see com::sun::star::sheet::SheetFilterDescriptor
> +    @since OOo 3.0
> +    */

As in the previous comment please add some empty lines and change the
position of the '*/'. Please update the @since tag to OOo 3.2.

================================================================================
sc/inc/datauno.hxx
================================================================================

> @@ -340,7 +341,8 @@
> 
> //	to uno, all three look the same
> 
> -class ScFilterDescriptorBase : public cppu::WeakImplHelper3<
> +class ScFilterDescriptorBase : public cppu::WeakImplHelper4<
> +                                   
com::sun::star::sheet::XSheetFilterDescriptor2,
>  									com::sun::star::sheet::XSheetFilterDescriptor,
>  									com::sun::star::beans::XPropertySet,
>  									com::sun::star::lang::XServiceInfo >,

I would add XSheetFilterDescriptor2 after XSheetFilterDescriptor, but
that's only a matter of taste.

> @@ -367,6 +369,11 @@
>  	virtual void SAL_CALL	setFilterFields( const ::com::sun::star::uno::Sequence<
>  								::com::sun::star::sheet::TableFilterField >& aFilterFields )
>  									throw(::com::sun::star::uno::RuntimeException);
> +    virtual ::com::sun::star::uno::Sequence<
::com::sun::star::sheet::TableFilterField2 > SAL_CALL
> +                            getFilterFields2()
throw(::com::sun::star::uno::RuntimeException);
> +    virtual void SAL_CALL	setFilterFields2( const
::com::sun::star::uno::Sequence<
> +                                ::com::sun::star::sheet::TableFilterField2 >&
aFilterFields )
> +                                   
throw(::com::sun::star::uno::RuntimeException);

Please add a comment '// XSheetFilterDescriptor2' here.

================================================================================
sc/source/filter/xml/xmldrani.cxx
================================================================================

> @@ -60,6 +60,7 @@
>  #include <com/sun/star/sheet/XDatabaseRanges.hpp>
>  #include <com/sun/star/sheet/XDatabaseRange.hpp>
>  #include <com/sun/star/table/CellRangeAddress.hpp>
> +#include <com/sun/star/sheet/TableFilterField.hpp>

Is this include really necessary?

> @@ -382,9 +383,10 @@
>  								pDBData->SetSortParam(aSortParam);
>  							}
>  							uno::Reference <sheet::XSheetFilterDescriptor>
xSheetFilterDescriptor(xDatabaseRange->getFilterDescriptor());
> -							if (xSheetFilterDescriptor.is())
> +                            uno::Reference< sheet::XSheetFilterDescriptor2 >
xSheetFilterDescriptor2( xSheetFilterDescriptor, uno::UNO_QUERY );
> +							if (xSheetFilterDescriptor2.is())
>  							{
> -								uno::Reference <beans::XPropertySet> xFilterPropertySet
(xSheetFilterDescriptor, uno::UNO_QUERY);
> +								uno::Reference <beans::XPropertySet> xFilterPropertySet
(xSheetFilterDescriptor2, uno::UNO_QUERY);

The first lines can be combined to

  uno::Reference< sheet::XSheetFilterDescriptor2 > xSheetFilterDescriptor2(
xDatabaseRange->getFilterDescriptor(), uno::UNO_QUERY );

After that the variable xSheetFilterDescriptor2 can be renamed to
xSheetFilterDescriptor.

> @@ -396,7 +398,8 @@
>  								
xFilterPropertySet->setPropertyValue(rtl::OUString(RTL_CONSTASCII_USTRINGPARAM(SC_UNONAME_USEREGEX)),
uno::makeAny(bFilterUseRegularExpressions));
>  								
xFilterPropertySet->setPropertyValue(rtl::OUString(RTL_CONSTASCII_USTRINGPARAM(SC_UNONAME_OUTPOS)),
uno::makeAny(aFilterOutputPosition));
>  								}
> -								xSheetFilterDescriptor->setFilterFields(aFilterFields);
> +                                if ( xSheetFilterDescriptor2.is() )
> +                                   
xSheetFilterDescriptor2->setFilterFields2(aFilterFields);

The second check xSheetFilterDescriptor2.is() can be removed.

================================================================================
sc/source/filter/xml/XMLExportDatabaseRanges.cxx
================================================================================

> @@ -55,6 +55,7 @@
>  #include <com/sun/star/sheet/XDatabaseRanges.hpp>
>  #include <com/sun/star/sheet/XDatabaseRange.hpp>
>  #include <com/sun/star/table/TableOrientation.hpp>
> +#include <com/sun/star/sheet/XSheetFilterDescriptor.hpp>

I think this iinclude can be removed.

> @@ -632,11 +645,13 @@
>  								if
(::cppu::any2bool(xPropertySetDatabaseRange->getPropertyValue(rtl::OUString(RTL_CONSTASCII_USTRINGPARAM(SC_UNONAME_STRIPDAT)))))
>  									rExport.AddAttribute(XML_NAMESPACE_TABLE, XML_HAS_PERSISTENT_DATA,
XML_FALSE);
>  							}
> -							uno::Reference <sheet::XSheetFilterDescriptor>
xSheetFilterDescriptor(xDatabaseRange->getFilterDescriptor());
> +							
> +                            uno::Reference <sheet::XSheetFilterDescriptor>
xSheetFilterDescriptor(xDatabaseRange->getFilterDescriptor());
> +                            uno::Reference< sheet::XSheetFilterDescriptor2 >
xSheetFilterDescriptor2( xSheetFilterDescriptor, uno::UNO_QUERY );

The last two lines can be combined to

  uno::Reference< sheet::XSheetFilterDescriptor2 > xSheetFilterDescriptor2(
xDatabaseRange->getFilterDescriptor(), uno::UNO_QUERY );

because the xSheetFilterDescriptor variable is not needed anymore. 
Then in the ScXMLExportDatabaseRanges::WriteDatabaseRanges() method
the xSheetFilterDescriptor2 variable can be renamed to xSheetFilterDescriptor.

================================================================================
sc/source/filter/xml/xmlfilti.hxx
================================================================================

> @@ -36,7 +36,8 @@
>  #include <com/sun/star/table/CellAddress.hpp>
>  #include <com/sun/star/table/CellRangeAddress.hpp>
>  #include <com/sun/star/sheet/FilterOperator.hpp>
> -#include <com/sun/star/sheet/TableFilterField.hpp>
> +#include <com/sun/star/sheet/FilterOperator2.hpp>
> +#include <com/sun/star/sheet/TableFilterField2.hpp>

Must TableFilterField.hpp still be included?

================================================================================
sc/source/ui/vba/vbarange.cxx
================================================================================

> @@ -77,7 +77,11 @@
> #include <com/sun/star/sheet/XCellRangeMovement.hpp>
> #include <com/sun/star/sheet/XCellRangeData.hpp>
> #include <com/sun/star/sheet/FormulaResult.hpp>
> +#include <com/sun/star/sheet/FilterOperator2.hpp>
>  #include <com/sun/star/sheet/TableFilterField.hpp>
> +#include <com/sun/star/sheet/TableFilterField2.hpp>
> +#include <com/sun/star/sheet/XSheetFilterDescriptor.hpp>
> +#include <com/sun/star/sheet/XSheetFilterDescriptor2.hpp>

I think the XSheetFilterDescriptor.hpp include is not necessary.

> @@ -4213,13 +4217,16 @@
>  	bool bAll = false;;
>  	if ( ( Field >>= nField )  )
>  	{
> -		uno::Sequence< sheet::TableFilterField > sTabFilts;
> -		uno::Reference< sheet::XSheetFilterDescriptor > xDesc =
xDataBaseRange->getFilterDescriptor();
> -		uno::Reference< beans::XPropertySet > xDescProps( xDesc,
uno::UNO_QUERY_THROW );
> +        uno::Reference< sheet::XSheetFilterDescriptor > xDesc =
xDataBaseRange->getFilterDescriptor();
> +        uno::Reference< sheet::XSheetFilterDescriptor2 > xDesc2( xDesc,
uno::UNO_QUERY );
> +        if ( xDesc2.is() )
> +        {
> +            uno::Sequence< sheet::TableFilterField2 > sTabFilts;
> +            uno::Reference< beans::XPropertySet > xDescProps( xDesc2,
uno::UNO_QUERY_THROW );

The first lines can be combined to

  uno::Reference< sheet::XSheetFilterDescriptor2 > xDesc2(
xDatabaseRange->getFilterDescriptor(), uno::UNO_QUERY );

After that the variable xDesc2 can be renamed to xDesc.

>  		if ( Criteria1.hasValue() )
>  		{ 
>  			sTabFilts.realloc( 1 );
> -			sTabFilts[0].Operator = sheet::FilterOperator_EQUAL;// sensible default
> +                sTabFilts[0].Operator = sheet::FilterOperator2::EQUAL;//
sensible default

The indentation of those lines and all the following is wrong.

> @@ -4333,7 +4341,10 @@
>  					lcl_SetAllQueryForField( pShell, rEntry.nField, nSheet );
>  			}
>  			// remove exising filters
> -			xDataBaseRange->getFilterDescriptor()->setFilterFields( uno::Sequence<
sheet::TableFilterField >() );
> +            uno::Reference <sheet::XSheetFilterDescriptor>
xSheetFilterDescriptor( xDataBaseRange->getFilterDescriptor() );
> +            uno::Reference< sheet::XSheetFilterDescriptor2 >
xSheetFilterDescriptor2( xSheetFilterDescriptor, uno::UNO_QUERY );
> +            if( xSheetFilterDescriptor2.is() )
> +			    xSheetFilterDescriptor2->setFilterFields2( uno::Sequence<
sheet::TableFilterField2 >() );

The first lines can be combined to

  uno::Reference< sheet::XSheetFilterDescriptor2 > xSheetFilterDescriptor2(
xDatabaseRange->getFilterDescriptor(), uno::UNO_QUERY );

After that the variable xSheetFilterDescriptor2 can be renamed to
xSheetFilterDescriptor.

================================================================================
xmloff/source/core/xmltoken.cxx
================================================================================

> @@ -2976,6 +2976,12 @@
>          TOKEN( "near-origin",                     XML_NEAR_ORIGIN ),
>          TOKEN( "dependency",             XML_DEPENDENCY ),
>  		TOKEN( "nav-order",				XML_NAV_ORDER ),
> +        TOKEN( "contains",				XML_CONTAINS ),
> +        TOKEN( "does-not-contain",				XML_DOES_NOT_CONTAIN ),
> +        TOKEN( "begins-with",				XML_BEGINS_WITH ),
> +        TOKEN( "does-not-begin-with",				XML_DOES_NOT_BEGIN_WITH ),
> +        TOKEN( "ends-with",				XML_ENDS_WITH ),
> +        TOKEN( "does-not-end-with",				XML_DOES_NOT_END_WITH ),

Please indent the last column with spaces instead of tabls.
Comment 122 lvyue 2009-06-03 03:59:06 UTC
Created attachment 62737 [details]
patch 2, based on DEV300m49.
Comment 123 gaozm 2009-06-05 09:25:25 UTC
Created attachment 62787 [details]
Updata the SpecificationDocument of issue35579.
Comment 124 thomas.benisch 2009-06-17 09:57:56 UTC
reassign to tbe
Comment 125 thomas.benisch 2009-06-17 10:23:38 UTC
set target OOo 3.2
Comment 126 thomas.benisch 2009-06-17 13:51:15 UTC
Fixed in CWS calc51. In addition to the latest patch from June 3, 2009
I increased the horizontal size of the condition listboxes in the
standard filter dialog as specified in the specification from
January 7, 2008. The following files are affected:

offapi/com/sun/star/sheet/FilterOperator2.idl  r273052
offapi/com/sun/star/sheet/TableFilterField2.idl  r273052
offapi/com/sun/star/sheet/XSheetFilterDescriptor2.idl  r273052
offapi/com/sun/star/sheet/makefile.mk  r273052

xmloff/source/core/xmltoken.cxx  r273054
xmloff/inc/xmloff/xmltoken.hxx  r273054
xmloff/inc/xmlkywd.hxx  r273054

sc/source/filter/excel/excimp8.cxx  r273055
sc/source/filter/excel/excrecds.cxx  r273055
sc/source/filter/xml/xmlfilti.cxx  r273055
sc/source/filter/xml/xmldrani.hxx  r273055
sc/source/filter/xml/XMLExportDatabaseRanges.hxx  r273055
sc/source/filter/xml/xmlfilti.hxx  r273055
sc/source/filter/xml/xmldrani.cxx  r273055
sc/source/filter/xml/XMLExportDatabaseRanges.cxx  r273055
sc/source/core/data/table3.cxx  r273055
sc/source/ui/src/filter.src  r273055
sc/source/ui/unoobj/cellsuno.cxx  r273055
sc/source/ui/unoobj/datauno.cxx  r273055
sc/source/ui/vba/vbarange.cxx  r273055
sc/inc/global.hxx  r273055
sc/inc/datauno.hxx  r273055
Comment 127 thomas.benisch 2009-07-06 14:06:29 UTC
TBE->OC: Please verify in CWS calc51.
Comment 128 oc 2009-07-22 12:15:01 UTC
Created attachment 63687 [details]
TestCaseSpecification
Comment 129 oc 2009-07-22 12:15:58 UTC
Created attachment 63688 [details]
Testdocument for Test Case Specification
Comment 130 oc 2009-07-22 12:17:10 UTC
verified in internal build cws_calc51
Comment 131 Joe Smith 2009-08-05 21:55:51 UTC
Testing DEV300_m54 on Fedora Linux 11:

New options are present in Data > Filter > Standard Filter > Condition:
 Contains/Does not contain
 Begins with/Does not begin with
 Ends with/Does not end with

Tested each singly and in some simple combinations.

All worked correctly.

Looks great--Thanks!
Comment 132 amy2008 2009-08-06 07:15:36 UTC
Verified in DEV300m54
Closing