When a READ event is done, then any CHANGED events are also fired.

How would you stop a CHANGED event from processing (is in a commuter module) after a READ.

Hi Barry,

It's raised from Windows for EditLines , so some of options could be :

1) Turn off the CHANGED event for the control before the READ using QUALIFYEVENT in a promoted READ handler and reset it after the READ

2) Use SYSTEM BLOCKEVENTS (bit of a sledgehammer approach, and might have side effects)

3) Have some sort of flag that checks to see if the READ has finished before allowing the "normal" CHANGED event processing to occur. This could be done per control or at a promoted level

e.g.

a) Set "In Read Flag" to TRUE

b) Execute READ

c) Post a "PostRead" OMNIEVENT (so it executes after the CHANGED events)

d) CHANGED events fire - looks for "In Read Flag" and ignores processing if set

e) Set "In Read Flag" to FALSE in the "PostRead" OMNIEVENT

etc.

Carl Pates

Hi Barry,

It's raised from Windows for EditLines , so some of options could be :

1) Turn off the CHANGED event for the control before the READ using QUALIFYEVENT in a promoted READ handler and reset it after the READ

2) Use SYSTEM BLOCKEVENTS (bit of a sledgehammer approach, and might have side effects)

3) Have some sort of flag that checks to see if the READ has finished before allowing the "normal" CHANGED event processing to occur. This could be done per control or at a promoted level

e.g.

a) Set "In Read Flag" to TRUE

b) Execute READ

c) Post a "PostRead" OMNIEVENT (so it executes after the CHANGED events)

d) CHANGED events fire - looks for "In Read Flag" and ignores processing if set

e) Set "In Read Flag" to FALSE in the "PostRead" OMNIEVENT

etc.

Carl Pates

Yes, they are editlines. I can see that the changed event is executed on each keystroke (did'nt know that).

So, to be more efficient and cut overheads, removed the changed event and did lostfocus checking to see if changed.

Works much better now.

Thank you.

View this thread on the Works forum...