1) SetMaxLen( 0 ) should IMHO mean "no limit" in both cases. 2) WTF is STRING_NOLIMIT, and how is it related to a MultiLineEdit? I see an EDIT_NOLIMIT, and that definition only makes sense for an Edit, not for a MultiLineEdit. It's STRING_LEN, which more or less a "no limit" for an edit which only holds one string. I can't see some NOLIMIT define for a MultiLineEdit...
Malte. Frank Schönheit - Sun Microsystems Germany wrote, On 10/23/06 11:59: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
