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];
      m_CtrlKey.GetWindowText(buffer,127);
                jj=DoSomeProcessingOnBuffer();  where the buffer contents are potentially changed, and jj is the new length
      m_ControlKey.SetWindowText(buffer);
      m_ControlKey.SetSel(jj,jj);
}

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

if(Updating)return;

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

Any information will be greatly appreciated.

Rick
rickatseasoftAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

AndyAinscowFreelance programmer / ConsultantCommented:
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)
0
mahesh1402Commented:
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.

MAHESH
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
rickatseasoftAuthor Commented:
Andy:

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
0
Cloud Class® Course: Amazon Web Services - Basic

Are you thinking about creating an Amazon Web Services account for your business? Not sure where to start? In this course you’ll get an overview of the history of AWS and take a tour of their user interface.

AndyAinscowFreelance programmer / ConsultantCommented:
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.
0
AndyAinscowFreelance programmer / ConsultantCommented:
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.
0
mahesh1402Commented:
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.

MAHESH
0
DanRollinsCommented:
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.
0
AndyAinscowFreelance programmer / ConsultantCommented:
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.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
System Programming

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.