• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1292
  • Last Modified:

ON_EN_CHANGE works differently on different computers, Why?

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.

3 Solutions
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)
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.

rickatseasoftAuthor Commented:

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
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

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.
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.
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.

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.
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.

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now