controls/edit.c not so clean - help please

[Carl Sopchak]

The following code is in the EDIT_MakeFit() function:

if ((es->buffer_limit > 0) && (size > es->buffer_limit)) {
                EDIT_NOTIFY_PARENT(es, EN_MAXTEXT, "EN_MAXTEXT");
                return FALSE;
        }
        if ((es->buffer_limit > 0) && (size > es->buffer_limit))
                size = es->buffer_limit;

Obviously, the second IF condition is never true, since it's the same as the 
prior IF, which does a 'return FALSE'.

EDIT_MakeFit() is ONLY called by EDIT_EM_ReplaceSel(), so it sppears that the 
second IF is attempting to limit the amount of text that is replaced to the 
buffer_limit.  Obviously, the first IF just notifies the parent that the 
limit would be exceeded, then returns without modifying the edit control.

Although EDIT_MakeFit() is only called from one place, EDIT_EM_ReplaceSel() is 
called all over the place, enumerated below.  Can anyone tell me if any of 
these invocations should (a) fail without replacing, (b) replace the limited 
amount of text, or (c) ignore the limit?

EDIT_WM_Clear() - Processes WM_CLEAR message - I assume it's moot here...
Processing of EM_REPLACESEL message.  See note below...
EDIT_EM_Undo() - Processes EM_UNDO and WM_UNDO messages
EDIT_WM_Char() - Process WM_CHAR message
EDIT_WM_Create() - Processes WM_CREATE message - I assume it's moot here...
EDIT_WM_Paste - Process WM_PASTE message
EDIT_WM_SetText - Process WM_SETTEXT message.  See note below...

Note:  Under the message EM_LIMITTEXT, MSDN states that WM_SETTEXT will not 
adhear to the limit, but doesn't mention any other text modification 
messages.  The man pages for the other messages do not mention how it's 
action is effected by the limit.  MSDN does state "The EM_LIMITTEXT message 
limits only the text the user can enter."

Unfortunately, I don't have a MS Windows box readily available to test some of 
these things out on...

- - - - - - - - -

Another question about this code from controls/edit.c/EDIT_WM_Char():

/* Protect read-only edit control from modification */
        if(es->style & ES_READONLY)
            return;  /* BECAUSE OF THIS... */

control = GetKeyState(VK_CONTROL) & 0x8000;

switch (c) {
        case '\r':
            /* If the edit doesn't want the return and it's not a multiline 
edit, do nothing */
            if(!(es->style & ES_MULTILINE) && !(es->style & ES_WANTRETURN))
                break;
        case '\n':
                if (es->style & ES_MULTILINE) {
                        if (es->style & ES_READONLY) {

/* ... WE NEVER GET HERE! */

EDIT_MoveHome(es, FALSE);
                                EDIT_MoveDown_ML(es, FALSE);
                        } else {
                                static const WCHAR cr_lfW[] = {'\r','\n',0};
                                EDIT_EM_ReplaceSel(es, TRUE, cr_lfW, TRUE, 
TRUE);
                        }
                }
                break;

The place that I marked "/* BECAUSE OF THIS... */" means that the code marked 
by "/* ... WE NEVER GET HERE! */" will never get executed.

My question:  In a read only multiline edit control, should a newline move the 
cursor to the beginning of the next line of text in the control?  (I could 
make this change, but don't have any way of testing it...)

- - - - -

Thanks for the help,

Carl

[Vincent Béron]

Carl Sopchak a écrit:
> The following code is in the EDIT_MakeFit() function:
>     if ((es->buffer_limit > 0) && (size > es->buffer_limit)) {
>             EDIT_NOTIFY_PARENT(es, EN_MAXTEXT, "EN_MAXTEXT");
>             return FALSE;
>     }
>     if ((es->buffer_limit > 0) && (size > es->buffer_limit))
>             size = es->buffer_limit;
>
>
> Obviously, the second IF condition is never true, since it's the same as the 
> prior IF, which does a 'return FALSE'.

See 
http://cvs.winehq.org/cvsweb/wine/controls/edit.c.diff?r1=1.56&r2=1.57 
for the a removed line between the two blocks (search for line 1451). 
The rest of the patch was to convert edit to Unicode; I don't know why 
this line was removed. Check also for ROUND_TO_GROW.

Vincent

[Carl Sopchak]

Thanks Vincent.

At least it make more sense as to how this got this way.  (The line that was 
missing was "size = ((size / GROWLENGTH) + 1) * GROWLENGTH;" for those 
interested...)

I guess that leaves the question, "Is there a case (besides WM_SETTEXT) that 
EDIT_EM_ReplaceSel should not fail if the limit is exceeded?"  What should 
happen if you try to paste (insert) 10 characters into a control with a limit 
of 30, but contents of 25 characters already?

Carl

On Monday, November 11, 2002 11:03 am, Vincent Béron wrote:
> Carl Sopchak a écrit:
> > The following code is in the EDIT_MakeFit() function:
> >     if ((es->buffer_limit > 0) && (size > es->buffer_limit)) {
> >             EDIT_NOTIFY_PARENT(es, EN_MAXTEXT, "EN_MAXTEXT");
> >             return FALSE;
> >     }
> >     if ((es->buffer_limit > 0) && (size > es->buffer_limit))
> >             size = es->buffer_limit;
> >
> >
> > Obviously, the second IF condition is never true, since it's the same as
> > the prior IF, which does a 'return FALSE'.
>
> See
> http://cvs.winehq.org/cvsweb/wine/controls/edit.c.diff?r1=1.56&r2=1.57
> for the a removed line between the two blocks (search for line 1451).
> The rest of the patch was to convert edit to Unicode; I don't know why
> this line was removed. Check also for ROUND_TO_GROW.
>
> Vincent

[Dmitry Timoshkov]

"Carl Sopchak"  wrote:
> The following code is in the EDIT_MakeFit() function:
>     if ((es->buffer_limit > 0) && (size > es->buffer_limit)) {
>             EDIT_NOTIFY_PARENT(es, EN_MAXTEXT, "EN_MAXTEXT");
>             return FALSE;
>     }
>     if ((es->buffer_limit > 0) && (size > es->buffer_limit))
>             size = es->buffer_limit;
>
>
> Obviously, the second IF condition is never true, since it's the same as the 
> prior IF, which does a 'return FALSE'.

Apparently the second IF can be removed. Regarding your EM_LIMITTEXT/WM_SETTEXT
question: only a test program can answer your question.

[skipped]
> Another question about this code from controls/edit.c/EDIT_WM_Char():

[skipped]
> The place that I marked "/* BECAUSE OF THIS... */" means that the code marked 
> by "/* ... WE NEVER GET HERE! */" will never get executed.
>
> My question:  In a read only multiline edit control, should a newline move the 
> cursor to the beginning of the next line of text in the control?

Under Windows2000 pressing Enter does nothing in the read-only edit control.

For obvious cases please send a patch (in a diff -u format).

Thanks.