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

On Feb 6, 2004, at 1:25 PM, Jim Hagen wrote:

I can't believe this thread is still lingering, but maybe it'll help if I explain the approach I've settled on after constructing many different data-editing UIs.

1) have a data object. It's best if all of the various bits of data can be gathered into a single object, though that mostly helps conceptually.

Got that already.

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.

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)?

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.

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.

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.

and neither do most programatic component-setting methods, so if you're in a situation where you're firing an unwanted action by setting up a UI component, you *know* you're doing something special. Scott-- we need the specific case if we're going to hear about this any further.

E.g. one combobox (CB1) selects Mode A or Mode B, depending on which mode is selected a second combobox (CB2) will contain either Set A or Set B from which the user can make a choice. During initialization CB1 is initialized from the document. This causes it to change the selections available in CB2 - which fires an event that is normally used to update the document as per the current selection of CB2. The actual current selection of the second combobox is of course stored in the document as well and will be initialized next. The issue is that CB2 has already activated the code that says CB2 wants to change the document state to X. That action must be suppressed because otherwise it would cause the state that the document currently has to be changed when it shouldn't be. As G.G. stated you need state to ignore the change (INITIALIZING) because this time around it isn't going to look redundant as it will if CB2 is initialized to the value already stored in the document.

You might say that I shouldn't update the document with CB2's selection changes.. I should wait till the users presses 'save'.. but the thing is that the current CB2 selection must also be reflected in other areas of the UI. Or when a user makes a 'real' change to CB2 I must send off a command to a server over the network.

That's one example. The more complicated the UI the more this can happen at other levels as well. I don't like complicated UI's but sometimes things can only be simplified so much.

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
_______________________________________________
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>)



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.