Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to distinguish between user selection and programatic selection with ListSelectionListener

Mostly, I'm agreeing with Scott here... scan down near the bottom for "OK. So here's the real answer" for uh, the real answer.

On Feb 6, 2004, at 11:52 AM, Scott Palmer wrote:

On Feb 6, 2004, at 1:25 PM, Jim Hagen wrote:
...
2) do NOT have actionListeners do anything other than set the related component's values...

If this were at all possible there would be no need for the addActionListener method, since the Swing components are already set up so the UI changes the components model.
Actions are for doing something, that's why they call them 'actions'. I just don't get this.

well, to be fair you did cut off my rambling in the '...', which is where I say stuff like 'unless you really need to'. In much of your case, you may really need to, but don't do it out of force of habit. I've done it myself, sometimes there's just no need. Most often, the UI object just needs to do what it's set up to do by default.


3) have a single method which compares the contents/state of the UI widgets to check to see if it's different from the ( unchanged ) data object. For large editors with lots of data, this is a somewhat ugly bit of code with lots of 'if ( myComponent.getState()!=data.somefield ) { isChanged=true }' business, but it's simple, not involving special models or lots of listener objects.

Other than in #5, when do you call this? How do you decide to set the modified indicator (dot in the close widget on a Mac)?

Good call. I don't, and setting the modified indicator dot is a good example of a reason why you might call it more often. Maybe that's something to stick in those actionListeners ( you might want them in some focusListeners, too ) for every single object on your page. For my users, that's overkill, they'll find out the document is modified when they change views or close the window anyway. But that's a nice touch.


4) changing a bit of actual 'document data' via the UI should not by itself start any intensive processing ( at most it should be a quick check to see if the new state is valid ) if at all possible.

But I need to update other parts of the UI to indicate how the changes made effect other things.

then update the UI. But not your document. And only update the UI through non-action-firing methods, i.e. JTextComponent.setText(..) or JComboBox.getModel.setSelectedItem(..)

There should be a "save" or "calculate" button which does that. This is a usability measure as much as a measure to save programming effort. Sometimes, like when a number field edit causes other numbers to adjust, you have to break this, but then see the last part of (2).

There are still other times when an app needs to say, "wait a sec I need to compute something first" that don't happen in places obvious like 'Save' or 'Update'. In my case selecting a sever to work on, which must then make contact with a server over and show options available to that server. The server communication is over the internet and therefore not all that fast relatively speaking.

which is a case where you need to break my guideline...

5) on window close, 'save', or document-selection change, you check the "is data changed" method and take the appropriate action.

Sure.

The short answer, though, is that needing to know the difference between 'user-initiated' and 'program-initiated' changes to a UI object's state should raise a red flag that your UI object is doing something a little 'too much' in it's action method, or doing something ( as in the original case that started this thread ) which should be handled differently, most likely elsewhere in the code. JTextComponent.setText() does not fire an action method,

Exactly - but other Swing components do. For the same reason I would call setText to update the UI I will need to set selections in lists or comboboxes, or radio buttons... but then they will do their 'actions' and try to update the UI elements that are related to them. Let's say that a combo box selection chooses a server, then when the selection changes a list of files on that server must be updated. The selected files in that list are are shown with more details in another area of the UI...etc.. the actions on combobox and list selection are all related. Initializing the state of one item will cause a ripple effect through a few others - but we don't want that to happen because then everything has to be so carefully managed so that initialization from a loaded document is not undone by an action that is triggered during initialization. The need to know the state - 'am I initializing', which is the same as 'do I need to do something with the even this time' .. for me it all comes down to did the user do something or is my code doing this.

OK. So here's the real answer : use JComboBox().getModel().setSelectedItem(..). Use JList.getListModel().setSelectedIndex(..). Buttons only fire actions on doClick(), you should using setSelected(), what's the issue there? Do you need a hidden button in the group to clear the selection, do you need to set the selected state for all of the buttons rather than running doClick() on just one, or is there some other issue??
...
I'm not sure that I'm explaining this well.. and maybe I'm just overlooking something simple. But so far it seems that things would be easier if I could simply suppress actions during initialization.

Scott

I think you did explain it well, unless for some reason my suggestions above don't address the problem. I'm still curious about the possible issue with radio buttons ( really "buttons in a buttongroup" ), but setting the models rather than the UI objects should solve your issue with combo boxes and lists...

-jim
_______________________________________________
java-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/java-dev
Be sure to read the FAQ http://developer.apple.com/java/faq/ before posting
Do not post admin requests to the list. They will be ignored.
References: 
 >Re: How to distinguish between user selection and programatic selection with ListSelectionListener (From: "John St. Ledger" <email@hidden>)
 >Re: How to distinguish between user selection and programatic selection with ListSelectionListener (From: Scott Palmer <email@hidden>)
 >Re: How to distinguish between user selection and programatic selection with ListSelectionListener (From: Jim Hagen <email@hidden>)
 >Re: How to distinguish between user selection and programatic selection with ListSelectionListener (From: Scott Palmer <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.