Field update loop problem

[Stephen]

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?

 

[Filip Larsen]

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,

 

[Andrew Thompson]

I was wondering if ..

...it was a good idea to warn readers that a post has
been cross-posted, and to set follow-ups for it?

Sure is!

(Note: Follow-ups set to c.l.j.gui only)

Andrew T.

 

[Daniel Pitts]

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?

I would think that your best solution is to only trigger refreshView if
the old value differs from the new value. I don't know about SWT, so
I'm not sure how you would implement this.

 

[Mark Rafn]

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

Won't the modification eventually stabilize? If the old value and the new
value are the same, maybe you don't want to refreshView().

Alternately, can you tell from the ModifyEvent what the source is?