TextField ValueChangeListener setValue()

Hi all:

I have a simple question (hopefully simple)... here is what I am trying to do and it doesn't seem to work..
Please help with any pointers as I am stuck.

Thanks
--
Sri

public class Test extends NavigationView implements ValueChangeListener
{

private TextField t = new TextField();

// other stuff...

private void initUI()
{
// create some layout ...
t.setImmediate(true);
t.addListener( this );
// add t to some layout...
}

// this is the method I want to focus on...
@Override
public void valueChange(ValueChangeEvent event)
{
// because valueChange will be fired every time the value is changed ... I thought by removing the listener before I clear the value here should work
t.removeListener( this );

String message = t.getValue().toString();
// do something with message ....

// when all done...
t.setValue(""); //keep it blank for next entry.

// put back the listener
t.addListener( this );
}
}

OK... after digging further in to removeListener() ... it occurred to me that removing listener is posted on to the EventRouter object which is not immediate (synchronous). Hence I see the problem of setValue("") firing another valueChange(...) event and going in to recursive mode...

But I thought, my if( !t.getValue().isEmpty() ) should catch to prevent the recursion... it's not working. I am missing something very silly and would appreciate some other pair of eyes to catch it.

Thank you in advance.
--
Sri

Sri L: OK... after digging further in to removeListener() ... it occurred to me that removing listener is posted on to the EventRouter object which is not immediate (synchronous). Hence I see the problem of setValue("") firing another valueChange(...) event and going in to recursive mode...

But I thought, my if( !t.getValue().isEmpty() ) should catch to prevent the recursion... it's not working. I am missing something very silly and would appreciate some other pair of eyes to catch it.

Thank you in advance.
--
Sri

Worked with the condition - it fooled me because it reenters at least twice in to the callback. Removing and adding listener in the callback method was totally unnecessary!