Hi Gao,
thanks for this patch. As Kohei already wrote, please attach the next
iteration of the patch to issue #35579#. In addition also the
specification needs to be updated. Although we work mainly with
specifications as odt document, Kohei is right that wiki is also an
accepted format. So it's up to you, which format you prefer.
Please see my comments concerning the patch below.
Thomas
================================================================================
sc/source/core/data/table3.cxx
================================================================================
--- 1019,1027 ----
}
}
else if ( (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 ||
Please use spaces instead of tabs for indentation. This also applies to
all other code changes.
--- 1039,1046 ----
else
GetInputString( static_cast<SCCOL>(rEntry.nField),
nRow, aCellStr );
! BOOL bRealRegExp = (rParam.bRegExp && ((rEntry.eOp ==
SC_EQUAL)
! || (rEntry.eOp == SC_NOT_EQUAL)));
Please remove this part from the patch, as you only added tabs.
--- 1088,1163 ----
}
else
{ // use collator here because data was probably sorted
+ if ( rEntry.eOp == SC_CONTAINS ||
rEntry.eOp == SC_DOES_NOT_CONTAIN )
+ {
+ // "aCellStr" is the string get
from the cell!
+ // "*rEntry.pStr" is the string
get from the Value Field!
+ BOOL bFound = FALSE;
+ xub_StrLen nStart = 0;
+ xub_StrLen nEnd =
aCellStr.Len();
+ bFound = (BOOL)rEntry.GetSearchTextPtr( rParam.bCaseSens
)->SearchFrwrd( aCellStr, &nStart, &nEnd );
+ switch (rEntry.eOp)
+ {
+ case SC_CONTAINS :
+ bOk = bFound;
+ break;
+ case SC_DOES_NOT_CONTAIN :
+ bOk = ( bFound == TRUE
) ? FALSE : TRUE ;
+ break;
+ }
Please add default statement in order to avoid warnings (which breaks
compilation).
+ }
+ else if ( rEntry.eOp == SC_BEGINS_WITH || rEntry.eOp ==
SC_DOES_NOT_BEGIN_WITH
+ || rEntry.eOp == SC_ENDS_WITH || rEntry.eOp ==
SC_DOES_NOT_END_WITH )
+ {
+ BOOL bFound = FALSE;
+ BOOL bRealFound = FALSE;
+
+ xub_StrLen nRoLen =
(rEntry.pStr)->Len();
+
+ xub_StrLen nStart = 0;
+ xub_StrLen nEnd =
aCellStr.Len();
+
+ xub_StrLen nRoEnd = nEnd;
+
+ if ( rEntry.eOp == SC_BEGINS_WITH || rEntry.eOp ==
SC_DOES_NOT_BEGIN_WITH )
+ {
+ bFound = (BOOL)rEntry.GetSearchTextPtr( rParam.bCaseSens
)->SearchFrwrd( aCellStr, &nStart, &nEnd );
+
+ if ( bFound && nStart
== 0 )
+ bRealFound =
TRUE;
+ }
+ else
+ {
+ String sRoTmpStr;
+
+ if ( nRoEnd == nRoLen )
+ sRoTmpStr =
aCellStr;
+ else
+ sRoTmpStr =
aCellStr.Copy( nRoEnd - nRoLen,nRoEnd - 1 );
+
+ bFound = (BOOL)rEntry.GetSearchTextPtr( rParam.bCaseSens
)->SearchFrwrd( sRoTmpStr, &nStart, &nRoLen );
+
+ if ( bFound )
+ bRealFound =
TRUE;
+ }
+ switch (rEntry.eOp)
+ {
+ case SC_BEGINS_WITH :
+ bOk = bRealFound;
+ break;
+ case SC_DOES_NOT_BEGIN_WITH :
+ bOk = ( bRealFound ==
TRUE ) ? FALSE : TRUE ;
+ break;
+ case SC_ENDS_WITH :
+ bOk = bRealFound;
+ break;
+ case SC_DOES_NOT_END_WITH :
+ bOk = ( bRealFound ==
TRUE ) ? FALSE : TRUE ;
+ break;
+ }
+ }
+ else
+ {
sal_Int32 nCompare =
pCollator->compareString(
aCellStr, *rEntry.pStr );
switch (rEntry.eOp)
I had some discussion with Eike with the outcome that
utl::TextSearch::SearchFrwrd() can only be used when searching with
regular expressions. Therefore the usage of SearchFrwrd() is not correct
here. Please use ::utl::TransliterationWrapper instead. And where
possible try to avoid string copy.
In addition, please also enhance the regular expressions branch
(l.1047, if ( bRealRegExp || bTestRegExp )) with your new filter
conditions.
================================================================================
sc/source/ui/dbgui/filtdlg.cxx
================================================================================
--- 88,94 ----
: ScAnyRefDlg ( pB, pCW, pParent, RID_SCDLG_FILTER ),
//
aFlCriteria ( this, ScResId( FL_CRITERIA ) ),
+ aFlSeperator ( this, ScResId( FL_SPERATOR ) ),
I would add aFlSeperator just after aFtVal. The order of the controls in
the C++ header file defines the tab order. Although in the case of a
fixed line this order is irrelevant I would stick to this rule.
================================================================================
sc/source/ui/inc/filtdlg.hxx
================================================================================
--- 135,141 ----
private:
FixedLine aFlCriteria;
+ FixedLine aFlSeperator; \
What's the trailing backslash for?
--- 156,162 ----
FixedText aFtCond;
FixedText aFtVal;
+
Please remove this part of the patch, you only added an empty line.
================================================================================
sc/source/ui/inc/filter.hrc
================================================================================
--- 73,79 ----
#define ED_VAL2 33
#define ED_VAL3 34
#define FL_CRITERIA 35
+ #define FL_SPERATOR 36
FL_SPERATOR => FL_SEPARATOR
================================================================================
sc/source/ui/src/filter.src
================================================================================
The conditions list box is wider than in Frank's mockup. I discussed
this with Frank and we agreed that this was a good choice, because this
assures that there's enough space for the entries in other languages.
The distance of the value list box to the right dialog edge is too
large. In addition the distance of the OK/Cancel/Help buttons to the
bottom dialog edge is also too large. Please use the 'Find & Replace'
dialog (Edit/Find & Replace...) as reference.
================================================================================
vcl/source/src/btntext.src
================================================================================
*** 71,82 ****
String SV_BUTTONTEXT_MORE
{
! Text [ en-US ] = "~More";
};
String SV_BUTTONTEXT_LESS
{
! Text [ en-US ] = "~More";
};
String SV_BUTTONTEXT_IGNORE
--- 71,82 ----
String SV_BUTTONTEXT_MORE
{
! Text [ en-US ] = "More ~Options";
};
String SV_BUTTONTEXT_LESS
{
! Text [ en-US ] = "Less ~Options";
};
This change is really dangerous. I haven't checked in detail, but I
assume that you change the text globally for a MoreButton, that means in
all places where a MoreButton is used the text changes from More to More
~Options. Therefore I think it's necessary to find another solution,
e.g. add the new resource text in calc and set the text at the button.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
