🚀 go-pugleaf

On 7/21/2004 at 4:18:27 PM, Ernesto Basc�n wrote:

> By example, I have my own "color chooser dialog"; I want the red, green,
> blue text fields to show their respective values when the user clicks a
> color selection panel, and I want the color selection panel selector to
> move on automatically everytime the text fields value change.
> 
> When the user clicks the color selection panel, an event tries to modify
> the text field values and that fact raises an event trying to modify the
> color selection panel that raises again the event to modify the text
> field values and so on.....

Got it.  There are two approaches  to do this sort of thing.

Common Model
------------

Swing components use a Model-View-Controller (MVC) architecture.  Ignoring
the controller part, which in Swing is kind of mixed in with the view, you
have two components:  The model, which holds a value, and the view, which
shows the value.

Swing UI (view) components will automatically create an appropriate model,
so it is easy to use them without worrying much about the model, but it is
always there.  When you get to the more complex components, being aware of
the separate model and view becomes more and more important.

In your case, you have 4 different view components that all show the same
value (or one aspect of that value).  If you write your code with a single
model component, then everything will be updated automatically and you
will will not have to listen to events and update the other components.

I do not know what your color selection panel looks like, so it is hard to
say exactly how you would implement this.  My guess is that the simplest
approach would be to create a model component composed of 3
PlainDocuments.  These documents would serve as the model for the text
fields.  This model component would listen to the documents and update the
color value when one of them changed.  When the color value actually
changed, it would fire a stateChanged() event.  The color selection panel
would listen for these stateChanged() events and update itself when that
occurred.

External Listeners
------------------

The second approach is what you have tried.  This is definitely not as
clean as the above approach, but it is a workable solution.  And in some
cases, the common model approach cannot be used because you cannot change
the model.

The biggest trap with using external listeners is the one you have fallen
into - recursive event firing.  The critical thing is that you only change
the value of one component when the value of the other component actually
changes.

If you do that, the change happens like this:  Both components start out
with the same value, say 1.  The user changes the value of component A to
2.  Component A notifies your listener that the value of A has changed,
and the listener sets the value of component B to 2.  As a result of this
change, Component B notifies your listener that its value has changed, so
that listener sets the value of component A to 2.  However, its value was
already 2, so no change has occurred and the component does not fire an
event.  This chokes off the recursive event firing.

Two of the possible pitfalls with this approach are temporary change
events and value rounding.  The first occurs when a component ends up
changing and then immediately changing back.  Since the component's state
*does* change, the recursion does not get choked off.  The rounding
pitfall occurs when a text field is used to display a value and then the
value is computed from the text field's string value.  In this case, the
value actually changes, even though it does not appear to be, since the
text display remains the same.  So again, the recursion is not choked off.

-- 
Regards,

John McGrath [TeamB]

---------------------------------------------------
Before sending me e-mail, please read:
    http://www.JPMcGrath.net/newsgroups/e-mail.html