Re: Field update loop problem
Stephen wrote:
I was wondering if anyone can suggest an elegant/simple way to solve this
problem in my SWT application. Obviously I could use some sort of "brute
force" method, but I would rather not.
I have a number of Text fields, and they each have a field modify listener
attached (this fires when text is modified in field). e.g.
sumInsuredText = new Text(this, SWT.BORDER);
sumInsuredText.setLayoutData(gridData3);
sumInsuredText.addModifyListener(new org.eclipse.swt.events.ModifyListener()
{
public void modifyText(org.eclipse.swt.events.ModifyEvent e)
{
//.. do stuff ..
comp.refreshView();
//.. do other stuff ..
}
});
Unfortunately, refresh view updates the field too (it has to, as the purpose
of the method is to update the contents in all the fields). This creates an
infinite loop, as the initial modification triggers modifyText(), which
called refreshView(), which triggers modifyText() etc.
I need refreshView() to be called each time the field is updated - without
causing an infinite loop. I'm not bothered whether this is on leaving the
field (would probably prefer this actually) or whether it's when the text is
changed.
I guess this is a fairly common problem, and I wonder if anyone has any
tried and tested solutions?
You are correct that this is a fairly common problem. I'm not familiar
with SWT, but in Swing the general solution usually lies along the lines
of breaking the update cycle somewhere.
One approach can be to set a flag in your anonymous ModifyListener so
that it skips the body of the modifyText in case its invoked recursively:
sumInsuredText.addModifyListener(new org.eclipse.swt.events.ModifyListener()
{
boolean updating = false;
public void modifyText(org.eclipse.swt.events.ModifyEvent e)
{
if (updating) return;
updating = true;
try {
//.. do stuff ..
comp.refreshView();
//.. do other stuff ..
} finally {
updating = false;
}
}
});
If you need a lot of such classes it is probably better to move that
logic into your own class to extend from, like:
public class UpdatingModifyListener implements ModifyListener {
boolean updating = false;
public void modifyText(ModifyEvent e) {
if (updating) return;
updating = true;
try {
safeModifyText(e);
} finally {
updating = false;
}
}
public void safeModifyText(ModifyEvent e) {
}
}
The above code breaks the cycle after first modification wave, which may
not be what you want if you have update code that changes the text
fields the user is currently modifying. In that case you may want to
break the event wave only if the text field is equal to its old value as
it was before modification or some similar criteria that captures your
update requirements. This is for instance build into the normal java
bean property change event notification so that you don't get events
unless the property actually has changed value.
Regards,
--
Filip Larsen