Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.gui > #633

Re: Field update loop pro

Show all headers | View raw

  To: comp.lang.java.gui,comp.l
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

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

Back to comp.lang.java.gui | Previous | Next | Find similar

Thread

Re: Field update loop pro "Filip Larsen" <filip.larsen@THRWHITE.remove-dii-this> - 2011-04-27 15:28 +0000

csiph-web