Apache OpenOffice (AOO) Bugzilla – Issue 35579
Standard filter requires more options..
Last modified: 2013-08-07 15:14:30 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
Created attachment 18415 [details] porposed patch against OOO113
Hi Niklas, please have a look. Frank
Attaching our patch vs. m79, updating various fields.
Created attachment 24154 [details] make it more usable & familiar.
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?
Yes. Target re-set.
Created attachment 24919 [details] much improved version ...
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.
*** Issue 46236 has been marked as a duplicate of this issue. ***
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".
Same issue: http://qa.openoffice.org/issues/show_bug.cgi?id=43156
Created attachment 34120 [details] Kohei's patch copied from issue 43156 that is to be closed as duplicate.
*** Issue 43156 has been marked as a duplicate of this issue. ***
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.
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.
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?
s/concensus/consensus/g
Kohei - your patch works well :o) Can we force of integration to OOo?
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.
Dear developers, any progress on this very important enhancement?
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.
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?
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
Thanks a lot. Any chance that we will see progress in Issue 35579? WBR, K. Palagin.
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
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
Eike, any progress on this issue? Regards, K. Palagin.
Notified the ODF chair of the need for additional values for the table:operator in table:filter-condition of section 8.7.3 ODF.
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
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
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
*** Issue 73204 has been marked as a duplicate of this issue. ***
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.
*** Issue 75543 has been marked as a duplicate of this issue. ***
*** Issue 75774 has been marked as a duplicate of this issue. ***
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
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
*** Issue 76311 has been marked as a duplicate of this issue. ***
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.
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.
Created attachment 47444 [details] Obsoletes Kohei's 20060212 patch; ignores leading/trailing whitespace, adds Excel import/export support.
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. :-)
Created attachment 47446 [details] Adds file format support to save the new filter settings into .ods files.
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
Created attachment 47473 [details] Previous version had a compilation error (sorry). This is the correct sc-standard-filter-options.diff patch.
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.
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
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.
> "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.
cc tbe
Created attachment 50685 [details] Add some filter-conditions and change the layout to the new dialog style by shifting OK/Cancel/Help buttons
Created attachment 50691 [details] A patch
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.
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.
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.
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.
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.
Created attachment 50931 [details] I have extended the UNO API
Created attachment 50932 [details] I have extended the UNO API
Created attachment 50933 [details] I have extended the UNO API
Created attachment 50934 [details] patch2
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.
TBE->LVYUE: This patch is fine. Thanks for all this work.
Created attachment 50950 [details] Extend the UNO API
Created attachment 50951 [details] Extend the UNO API
Created attachment 50952 [details] Extend the UNO API
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 */
Created attachment 51221 [details] A patch about the XML import/export
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
Extend filter.
Created attachment 51242 [details] A new patch about the XML import/export (1)
Created attachment 51243 [details] A new patch about the XML import/export (2)
Created attachment 51244 [details] A new patch about the XML import/export (3)
Created attachment 51245 [details] A new patch about the XML import/export (4)
Created attachment 51283 [details] A patch about the XML import/export (offapi)
Created attachment 51284 [details] A patch about the XML import/export (sc)
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
TBE->GAOZM: sc.patch doesn't compile. There are several undeclared indentifiers: XML_CONTAINS, XML_DOES_NOT_CONTAIN, etc.
Created attachment 51558 [details] A patch about the XML import/export (offapi) (1)
Created attachment 51559 [details] A patch about the XML import/export (sc) (1)
Created attachment 51560 [details] A patch about the XML import/export (xmloff) (1)
Created attachment 51584 [details] A new patch. the patch to the XML import/export (xmloff) (1) above is wrong.
Created attachment 51696 [details] A new patch. the patch to the XML import/export (xmloff) above is wrong
Created attachment 52020 [details] Another patch about the XML import/export (sc)
Created attachment 52021 [details] Another patch about the XML import/export (offapi)
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() ); }
Created attachment 52067 [details] What about this patch about the function ScXMLExportDatabaseRanges::WriteFilterDescriptor()?
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
Created attachment 52183 [details] A patch about the XML import/export。
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
Created attachment 53273 [details] A patch about issue 35579
Created attachment 53402 [details] A patch about vbarange.cxx
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
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
Created attachment 53436 [details] A new patch about the file vbarange.cxx
Hi, Thomas What about the last patch about the file vbarange.cxx?
Created attachment 53557 [details] A new patch about issue 35579.
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
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
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.
*** Issue 89549 has been marked as a duplicate of this issue. ***
Created attachment 54418 [details] A complete patch to issue 35579.
*** Issue 90605 has been marked as a duplicate of this issue. ***
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)...
@tuharsky: apparently they apply some go-oo patch; whatever patch that may be, most certainly not the one under discussion here.
Hi,all Could you review the last patch? Thank you.
*** Issue 84874 has been marked as a duplicate of this issue. ***
> Additional comments from gaozm Mon Jul 14 02:15:21 +0000 2008 ------- > Could you review the last patch? Nobody can???
@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
As a *user* who wants to use native OOo, I asked for *developers* who can *аpply a patch and compile OOo*.
The last patch based on DEV300_m2.
Please add , contains , start with , end with in the filter option
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?
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.
@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
*** Issue 90923 has been marked as a duplicate of this issue. ***
Created attachment 61169 [details] Update the patch.
maoyg: On which milestone is your patch from March 25, 2009 based on?
tbe:I used OOoDev300_m42 code.
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.
Created attachment 62737 [details] patch 2, based on DEV300m49.
Created attachment 62787 [details] Updata the SpecificationDocument of issue35579.
reassign to tbe
set target OOo 3.2
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
TBE->OC: Please verify in CWS calc51.
Created attachment 63687 [details] TestCaseSpecification
Created attachment 63688 [details] Testdocument for Test Case Specification
verified in internal build cws_calc51
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!
Verified in DEV300m54 Closing