riched20: block recursive notification

[Matt Finnicum]

On 12/30/06, Clinton Stimpson <cjstimpson at utwire.net> wrote:
>
> This patch blocks riched20 from recursivly sending an EN_CHANGE
> notification.
> Fixes bug 6985.
>
> Thanks,
> Clinton Stimpson
>
> ChangeLog
>     Block recursive EN_CHANGE notifications.

If you're adding a new variable to the ME_TextEditor structure then
you should probably also initialize it in ME_MakeEditor.

Naming the variable "notify" is somewhat ambiguous, and there seems to
be an established convention of naming int's with the 'n' prefix, like
nNotifiy. You should probably comment to explain what the variable is
for or attempt to name it something more self evident. Maybe a BOOL
would be more appropriate, unless you're intending to extend this to
other notify calls as well.

Lastly, I don't see why this patch is needed - it only prevents the
ME_SendOldNotify (which just calls  SendMessageA) from triggering
another call of that same EN_CHANGE notification. I don't see why
calling SendMessageA would cause ME_UpdateRepaint to be called. Maybe
the application you're working with, in processing the EN_CHANGE
message, is sending another message to which we wrongly are sending an
EN_CHANGE notification - so thus we should fix our message handling of
that.

A quick look at MSDN shows that "The EN_CHANGE notification message is
sent when the user has taken an action that may have altered text in
an edit control." - it seems that we may be sending them whenever any
action (user or not) has altered text in the control. We really could
use some tests to see what should generate EN_CHANGE messages.

Another possibility is that we don't handle the case where (again,
from MSDN) "The EN_CHANGE notification is not sent when the
ES_MULTILINE style is used and the text is sent through WM_SETTEXT." -
perhaps your application has ES_MULTILINE set and uses a WM_SETTEXT in
response to the EN_CHANGE notification?

Thanks for your help with richedit,
--Matt Finnicum