On 12/30/06, Clinton Stimpson cjstimpson@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