We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you a podcast all about Citrix Workspace, moving to the cloud, and analytics & intelligence. Episode 2 coming soon!Listen Now


ON_EN_CHANGE works differently on different computers, Why?

Medium Priority
Last Modified: 2013-11-20
I am developing code that will examine each character entered into a CEdit Control, and do some processing. such as

void CPDScan::OnChangeKey()
      // TODO: If this is a RICHEDIT control, the control will not
      // send this notification unless you override the CDialog::OnInitDialog()
      // function and call CRichEditCtrl().SetEventMask()
      // with the ENM_CHANGE flag ORed into the mask.
      // TODO: Add your control notification handler code here
                char buffer[128];
                jj=DoSomeProcessingOnBuffer();  where the buffer contents are potentially changed, and jj is the new length

My problem is that on my computer (Windows 2000), the function is not recursive.  That is to say that when the function calls SetWindowText(), the EN_CHANGE message isn't sent again---at least it doesn't present itself.  On a different Windows 2000 computer, the SetWindowText() function triggers another message, and ultimately there is a stack overflow because it gets caught in a recursive loop.

I suppose that the best way to fix it is to set a BOOLEAN as in BOOL Updating, and at the beginning of the function do something like


But why does it work differently on different computers running what I believe is that same OS.

Any information will be greatly appreciated.

Watch Question

AndyAinscowFreelance programmer / Consultant

Behaviour you experience - ???
Would it not be better to create your own CEdit based class and do the processing in there (OnKeyDown event for instance)
IT Professional
Top Expert 2005
SetWindowText in a EN_CHANGE handler will case an infinite loop, unless there are some special handlers that will skip the second call to the EN_CHANGE handler when it came from within the EN_CHANGE handler to beginwith.

Subclass your control and override the EN_CHANGE message. That way you can control its processing.


Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts



Probably so, but I am still interested in understanding the process.  I am from the Unix world, and things like this happen there only if there is a configuration difference, and that is fairly easy to check.  What would make this happen in Windows?

Thanks again, Rick
AndyAinscowFreelance programmer / Consultant

With the same code on the same OP system the only explanation I can think of is that somewhere there is a different dll that contains a bug, or a hook that is corrupting something.
AndyAinscowFreelance programmer / Consultant

ps.  I understand the desire to know understand the process.   Sometimes one has to live with 'features' in windows.  :-(

Maybe someone else has a good idea as to what is going on.
mahesh1402IT Professional
Top Expert 2005

its experienced on a particulat PC only ? or you tried this on several ?
if its happening only for a particular then its machine specific as said due to corruption/virus problem.

Author of the Year 2009
I agree with AndyAinscow and mahesh1402... before blaming it on a particular version of the operating system (unlikely in this case), try the code on several different computers with the (suspected) problem OS.   It will probably be found to be something that is specific to a particular computer -- a buggy DLL or device driver or the like.

Also, there are several variations of the RichEdit control handler... look to dates and version numbers of these on the two computers.
AndyAinscowFreelance programmer / Consultant
Back to the processing.
If you had the code in your own (CEdit derived) class then you shouldn't be faced with the problem of the EN_CHANGE message being passed once/multiple times.

You trap the key in the class, do the processing then update the edit - one EN_CHANGE message is generated.  Also you can reuse the code in another dialog just by creating a control of your derived CEdit.  Having the code in the dialog means you need to copy/paste code should you require it being implemented on another dialog.  

Also if you had two controls on the same dialog then handling it in the dialog means you have to check which control is being processed - the code becomes more complex.
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.