On Windows NT, when setText() is invoked on a textfield, a TextEvent is
not generated.
 
The attached application demonstrates this.

N/A

This is a duplicate of the bug #4028580.

  xxxxx@xxxxx   1999-12-07

This is also true for Win32, Version 1.1.5.
What is right? To create an event or not?
If it's right that the creation of an event
will be the default behaviour, the text attribute
of an TextComponent is an exception: Other attributes
don't have an associated event (e.g. a set...Color
does not create an event like ColorChanged). So is
it consistent to create an event on an TextComponent?
What are the general design rules for event creation
on attribute changes (not user events) in the AWT?

I agree with other comments.  TextEvents should
NOT be generated as a result of a call to setText.
No other component generates events when the state
is set from the program.  It is useful to know when
the user has changed the text but If I set the text
from code (to implement a Refresh button, for example), 
I do not want a TextEvent.

If you are using a applet, Netscape and IE both behave differently.  Netscape
generates a TextEvent whereas IE does not.
I would prefer not to have TextEvents on setText, since you can then clearly
differentiate between User and Program events.
Possible solution for now maybe one of two.
1.  If you want only program to control, ignore textEvents and execute a
method.
2.  Understand how events are posted in event queue, then either add an
additional event or remove unwanted events from the queue. (Security may avoid
this)

This is particularly bad if you want to have cross-dependencies between text
fields, 
(eg. when text from field A gets changed, change field B accordingly; and vice
versa)
meaning that you need to distinguish between events generated by setText() and 
a user action.
Especially since sun's VM has (for your "convenience") put the actual
text-setting
on a different thread than the execution of setText().  This means that if you
set a flag
to avoid the infinite loop, it won't work.
eg. 
public void textValueChanged(TextEvent evt) {
  if (ignore) return;
  ...
}
void adjust() {
  ignore=true;
  field.setText("abc")
  ignore=false;
}
the 'ignore' flag has no effect on the setting, since the adjust function has
come & gone 
before the field actually changes.
This was VERY poorly thought out.