Even within what Java/Swing supplies, there still seems to be a good
deal of room for various implementations.  For instance, if you have
cut & copy buttons in a toolbar, the chances are they can apply to more
than one control in your application: you may have text-editing
controls (JTextComponent derived), and you may also have some other
sort of object manipulation editor.  Usually then the buttons need to
enabled if and only if some control is focused that can currently
support the relevant action.  Problem is, there isn't really a
consistent interface to determine when that state may change and how to
query it.  For a JTextComponent, usually you'd want to add a
CaretListener that sets the Actions' enable status depending on whether
there is text selected.  But there may be other events that cause
whether text is selected to change, for instance, programmatically
changing the text on the underlying document, that are not trapped by
this.  For some other sort of control, there may be a rather different
way of trapping whether the current selection has changed.  And then
you need to way of trapping every time focus is moved from one control
to another, just in order to determine which control should be
determining whether the commands are enabled.
Further more, while there is built-in support for controlling the
enable status of buttons, the same is not true for the "selected"
state, i.e. for toggle-style buttons that may reflect attributes of the
current selection (e.g. the "Bold" button in a word processor).

I have to say, after spending some time trying to get all this to work
for me, MFC's command update mechanism, which basically constantly
refreshes the status of all toolbar buttons every time there is a lull
in the windows message queue, is a good deal simpler to work with.  You
never have to worry about which listeners to install, and 90% of the
time it correctly takes care of automatically querying the currently
focused window/control.  I'm actually curious if someone has attempted
to emulate this in Java - if not, I'm extremely tempted to do so
myself.   I doubt there would be a way to trap "idle" message queue
events, but even if it works by polling at a fixed interval, it would
do the job.

[me:]

Ah, well...   Apologies for the misdirect, I thought it looked relevant, but
you are right, it is not.

I agree, but I don't think that sort of event was what the quoted  passage was
referring to.  I take it to mean that if we are interested in, say, whether the
text field contains a valid number, then we should be Observing the state of
the text field's Model -- if that is a String (or some sort of value holder
containing a String) which parses as a valid number then other UI elements will
update themselves accordingly.

But the specific actions you mention are not Model-related in the MVC sense --
they are, I think, the responsibility of the Controller.  What you have is a
pattern where you have a sort of generic controller-like object, installed near
the application's top level, which responds to user input by finding another
contoller and invoking that controllers' specific cut, paste, or whatever code.
And....

.... as you note, that isn't too simple.

(BTW, the non-Java UI system I mentioned before has exactly the same problem
with buttons and toolbar buttons with invoke actions "for" some other
component.)

   -- chris

   -- chris