Hi, both MultiLineEdit (svtools/svmedit.hxx) and its base class Edit (vcl/edit.hxx) have a method void SetMaxTextLen( xub_StrLen nMaxLen );
Before integration of CWS warnings01, those were non-virtual methods, with warnings01, they have been changed to be virtual. An unexpected side effect of this is caused by different semantics of both methods in a special case: aEdit.SetMaxTextLen( 0 ); printf( "%i", (int)( aEdit.GetMaxTextLen() == STRING_NOLIMIT ) ); aMLEdit.SetMaxTextLen( 0 ); printf( "%i", (int)( aMLEdit.GetMaxTextLen() == STRING_NOLIMIT ) ); will result in 1 0 Oops, Edit::SetMaxTextLen silently interpreted "0" as "no limit at all", whereas MultiLineEdit doesn't. Speaking strictly, since nowadays both are implementations of the same interface, one of both is violating it's contract - but which one? I'd like to change MultiLineEdit::SetMaxTextLen to conform to Edit::SetMaxTextLen's semantics (unfortunately, I have some code which relies on Edit's behaviour, even when confronted with a MultiLineEdit). However, this implies that any code which *intentionally* sets a MaxTextLen of 0 at a MultiLineEdit would then misbehave. Is anybody aware of such code? How would you judge the risk such code exists (does it make sense to have a MaxTextLen of 0?) without us knowing about it? Thanks & Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
