Hi Malte, > There are two if statements in edit.cxx that would have to be changed. > > The best fix would be to get rid of EDIT_NOLIMIT, and handle > mnMaxTextLen == 0 correctly.
Yes. > I for sure don't want to see some "virtual bool IsUnlimitedTextLen() > const;". Why? That's a much cleaner solution than imposing a magic^W special semantics on a special value - no matter if "0" or "EDIT_NOLIMIT". > But this change might break some others code, so it seems that for now > it's better for you to handle Edit and MultiLineEdit different. Yes :( > I wonder: If behavior changed with WARNINGS01, because of method is now > virtual, it can only mean that MaxTextLen for (your instances of) > MultiLineEdit didn't work before, because you only changed the member > from the Edit, not from the MultiLineEdit... Well, the code is flawed, anyway, as I know by now: Some base class calls Edit.SetMaxTextLen( 0 ), and some derived class (which has more knowledge) calls MultiLineEdit::GetMaxTextLen. Before the change, the latter returned EDIT_NOLIMIT *by chance*, since that's the MultiLineEdit-default set in TextView::TextView (EDIT_NOLLIMIT == STRING_MAXLEN). After warnings01, SetMaxTextLen is handled in the MultiLineEdit, which preserves the 0. Since this is compared with EDIT_NOLIMIT for special handling, it triggered a bug there. So, I need to fix my code anyway. However, having overloaded methods with different "special values" still leaves a bad taste .... 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]
