I have 2 questions for this
First question:
What's the best way (in terms of performance) to add a ListSelectionListner event to JTable.
This:
myTable.getSelectionModel().addListSelectionListener(this);
Or this:
myTable.getSelectionModel().addListSelectionListener(new ListSelectionListener() {
#Override
public void valueChanged(ListSelectionEvent e) {
//Do my stiff here...
}
}
});
Second question:
I have this code:
myFirstTable.getSelectionModel().addListSelectionListener(this);
mySecondTable.getSelectionModel().addListSelectionListener(this);
How can I know the JTable that fired the ListSelectionListner event ?
Part 1
Irrelevant, neither is better or worse from the perspective of performance, it will come down to needs. Obviously if you have a single listener added to multiple tables it would be more efficient from a memory point of view
Which you would use would come down to needs and what you are trying to achieve
Part 2
Use the ListSelectionEvent#getSource method to determine what actually triggered the event
Related
I have something like this.
Grid<Stock> mygrid = new Grid<Stock>(store, cm)
{
#Override
protected void onAfterFirstAttach()
{
super.onAfterFirstAttach();
//here do the binding for the cell elements that have myclass
}
};
And for the view of mygrid I have this
view.setViewConfig(new GridViewConfig<Stock>()
{
#Override
public String getRowStyle(Stock model, int rowIndex)
{
return "";
}
#Override
public String getColStyle(Stock model, ValueProvider<? super Stock, ?> valueProvider, int rowIndex, int colIndex)
{
String style = "";
if(SOME_CASE)
{
style = "myclass";
}
return style;
}
});
What I want to do is onAfterFirstAttach I want to add some listener/handler that during hover will do something, let's say for the sake of simplicity, give an alert.
Is what I'm trying to do possible? Can I accomplish what I want without using JSNI or a library like gwtquery? Is it sure that onAfterFirstAttach all the cells that should have the class myclass will be available and accessible? If yes how can I attach the listener/handler that I want?
The questions seem a lot, but I believe they are all interconnected.
I'm using GWT 2.6 with GXT 3.1 on top of it.
Update
I forgot to mention that a feasible solution would be to add a listener for the mouse move on the whole grid, and then get each cell and check if it has the required class, but this seems such an overkill. There must be a simpler way.
A browser fires native events (click, focus, blur, etc.) regardless of whether you need them. These events "bubble up" the DOM tree giving you a chance to "listen" to them at the right level.
In your example you can create 30 listeners at the cell level, waiting for something to happen in "their" cell. This is a heavy (30 objects) and slow (it takes time to build and bind all of them) solution. Alternatively, you can create a single listener at the grid level, which listens to all events that bubble up from the cells and decides if something needs to be done or an event should be ignored. A single listener is lighter and can be created faster. On the flip side, it needs to examine events, although it's usually a fast and efficient operation (e.g. checking of an event source has a particular class name). Note also that this operation takes time when a browser typically does not have much to do anyway, so examining events only to ignore them does not impact user experience.
In my experience a single listener is almost always a better solution, although modern browsers and computers are so fast that the difference is rarely noticeable.
I'm trying to find a way to detect changes in which column the user selected in a JTable. I did some poking around and it appears that you need to somehow use a TableColumnModelListener in order to detect the changes, but that doesn't seem to fire an event when you change the column you have selected.
You need to add a ListSelectionListener instead. That will capture selection events. Here are some Swing tutorials that go further in depth:
http://download.oracle.com/javase/tutorial/uiswing/events/listselectionlistener.html
http://download.oracle.com/javase/tutorial/uiswing/components/table.html#selection
From what I read, I think you need to add a MouseListener to your table, which for example in mouseClicked will get the row and column using the following code, below:
table.addMouseListener(new MouseListener()
{
#Override
public void mouseClicked(MouseEvent e)
{
Point pnt = evt.getPoint();
int row = table.rowAtPoint(pnt);
int col = table.columnAtPoint(pnt);
}
}
It should work great for you I have used similar thing myself before.
BTW it look similar to the problem I found on coderanch, link:
http://www.coderanch.com/t/332737/GUI/java/detect-single-click-any-cell
Good luck, Boro
If by "change" you mean changing the value of a cell then you can use an AbstractTableModel and implement the fireTableCellUpdated method
i think this not a specific problem to me; everybody might have encountered this issue before.
To properly illustrate it, here's a simple UI:
As you can see, those two spinners are controlling a single variable -- "A". The only difference is that they control it using different views.
Since these two spinners' displaying values are synchronized, cyclic event shows up.
If i change the top spinner, "A" will be changed and the bottom spinner's value will also be updated accordingly. However, updating the bottom spinner's call (such as setValue) will also trigger another event instructing the top spinner to update based on the bottom spinner's value. Thus creates a bad cycle which can eventually cause a StackOverFlow exception.
My previously solution is kinda cumbersome: i placed a guarding boolean to indicate whether the 2nd updating call should be performed.
Now i'd like to ask "how can i handle such situation elegantly? ( in general, not specific to spinners )"
thx
Update:
Since i've got 2 answers suggesting me to utilize the observer structure, i have to say something about it.
Like what i've said, it's great but far from being perfect. Not only because of its inherent complexity, but also Its inability to solve the problem.
Why? To see the reason, you must realize the tight coupling of the View and Model-Controller in Java Swing. Lets take my spinner UI for an example. Suppose the variable A is actually an Observer object. Then, after firing the first state change event from the top spinner, the Observer "A" will update its value and fire a PropertyChange event to notify the bottom spinner. Then comes the 2nd updating which updates the bottom spinner's View. However, changing bottom spinner's view inevitably triggers a redundant event that will try to set "A"'s value again. Afterwards, the deadly loop is fully constructed and the stack overflow will be thrown.
In theory, the Observer model tries to solve the direct cycle by introducing 2 independent feedback paths. The chained updating odds(in event-response codes) implicitly form a bridge connecting both paths, making a cycle again.
Going back to Model-View-Controller, think about what your Model is, and what your View is.
In your current implementation, you have two models (one for each Spinner control), and they're being synced through the View layer.
What you should be doing though is share the same backing model. For the spinner with a subtracted value, create a proxy to the original model. ie:
class ProxySpinnerModel implements SpinnerModel {
getValue() { return originalSpinner.getValue() - 10 }
setValue(v) { originalSpinner.setValue(v+10) }
}
spinnerA = new JSpinner()
spinnerB = new JSpinner( new ProxySpinnerModel( spinnerA.getModel() ) )
Now, you don't need to add listeners, since they're both working off the same model and the default implementation (the originalModel) already has change listeners which it fires to the view.
Problem Solved
I've got many different suggestions. Particularly,
i want to thank Marc W & Reverend Gonzo. I'm here to make a summary for these ideas; this can save your time navigating thru big chunk of texts.
This problem can be easily bypassed if you carefully decouple the View and Model-Controller.
The dead cycle is caused by dependent writes: write_1 -> write_2 -> write_1 ->.... Intuitively, breaking the dependency can solve the problem elegantly.
If we look into the problem in depth, we can find updating the corresponding views doesn't necessarily involves an external write call. Actually, a view only depends on the data it's representing. Known this, we can then re-write the logic as follow: write_1 -> read_2 & write_2 -> read_1.
To illustrate this idea, lets compare the 3 methods mentioned by different posters:
alt text http://www.freeimagehosting.net/uploads/2707f1b483.png
As you can see, only the proxied view can solve all the dependency thus it's the generic solution for this knid of problem.
In practice, it can be implemented as something like this (in your event-response codes):
setValue(newValue);
anotherSyncUI.parse(); // not anotherSyncUI.setValue() any more
anotherSyncUI.repaint();
No more loops. Solved.
It's a bit complicated, but you could make A actually be an object that's observable. Both spinners (or whatever needs to update itself based on A's value) would then observe A. Whenever A changes, the spinners (or again, whatever object) update themselves to reflect the new value of A. This decouples the spinners' logic from one another. In your example here, the spinners should not be coupled to one another because they really have nothing to do with each other. Instead, they should both simply be bound to A and take care of their own view updating individually.
Whenever the value in the first spinner is changed, you would simply update A's value to match it. Whenever the value in the second spinner is changed, you would of course add 10 to its value before assigning it to A.
Update
In response to the update to your original question, my answer is that the spinners do not listen to one another's change events. Have a separate event handling method for each spinner. A user clicking the up or down arrows in the spinner generates a different event than calling setValue on the spinner programmatically, correct? If the spinners are completely independent of one another, there will be no infinite loop.
E.g. for the second spinner, calculate A-10 and then compare it to the current value of the spinner. If it's the same, do nothing, ending the infinite loop. Similarly for the first spinner.
I think there are also ways to update the spinner's model in a way that doesn't fire an event, but I don't know them off the top of my head.
Use a single SpinnerModel for both JSpinners. See the following code:
Note that the call to setValue() is only made once each time a new value is defined by one of the JSpinners.
import java.awt.BorderLayout;
import javax.swing.*;
public class Test {
public static void main(String[] args) {
JFrame jf = new JFrame();
SpinnerModel spinModel = new MySpinnerModel();
JSpinner jspin1 = new JSpinner(spinModel);
JSpinner jspin2 = new JSpinner(spinModel);
jf.setLayout(new BorderLayout());
jf.add(jspin1, BorderLayout.NORTH);
jf.add(jspin2, BorderLayout.SOUTH);
jf.pack();
jf.setVisible(true);
jf.setDefaultCloseOperation(3);
}
}
class MySpinnerModel extends AbstractSpinnerModel {
private int _value = 0;
private int _min = 0;
private int _max = 10;
#Override
public Object getNextValue() {
if (_value == _max) {
return null;
}
return _value + 1;
}
#Override
public Object getPreviousValue() {
if (_value == _min) {
return null;
}
return _value - 1;
}
#Override
public Object getValue() {
return _value;
}
#Override
public void setValue(Object value) {
System.out.println("setValue(" + value + ")");
if (value instanceof Integer) {
_value = (Integer) value;
fireStateChanged();
}
}
}
It seems you're really observing the wrong thing. From the example given I presume what you want to detect is the user's actions on the controls, not the changes in the values themselves. As you've outlined, changes in your model are reflected in the values of the spinners, and it is this which forms the infinite loop of events.
However, diving further into the UI implementation may not be the answer you want. In that case I'd say the best you can do is either your current guard solution, or to better extract the logic into your model (similar to what Marc and William have said). How that can be done will depend on the 'real world' model behind a particular implementation of the provided puzzle.
As a rule, your model should not be defined by your GUI. Ie, the SpinnerModel that backs each JSpinner should not be your value A. (That would be a horribly inelegant tightly coupled dependency on a particular view.)
Instead, your value A should either be a POJO or a property of an object. In which case, you can add PropertyChangeSupport to it. (And presumably have already done so in any case, as you want your spinners to update automatically if A is changed by other parts of your program).
I realise this is similar to Marc W's answer, and you were concerned that it's "complicated", but PropertyChangeSupport does almost all of it for you.
In fact, for trivially simple cases, you can just use a single class that wires a "setProperty" method through to a "firePropertyChange" call (as well as storing the value in a HashMap for any "getProperty" calls).
I don't really want to solve your problem but I find it interesting. I have already been confront to it and solved it each time a different way. But when I think about the 'why ?' and not about the 'how ?' am staying perplexed.
This problem only exists because I am using an automatism (MVC) which had to help me, and exactly in that way. The art how the components are used make this automatism a barrier to a beautiful code.
Why do set #setEvent() has to produce the same event as a GUI action?
Though, my opinion is also pretty close to Observer pattern but it is a bit lighter than that!!!
Have A as a variable with a setter
private Integer A;
setA(int A)
{
this.A = A;
refreshSpinners();
}
refreshSpinners()
{
setSpinnerA();
setSpinnerAMinus10();
}
setSpinnerA()
{
// show value of A
}
setSpinnerAMinus10()
{
// show value of A-10
}
A shout out to the Swing gurus out there!!
I've been doing Swing programming for several years but have always been unclear on this.
As you know Swing/AWT gives you several ways to execute a particular action when a button is clicked. I've seen it done several different ways in the applications I've worked on. The project I'm currently working on tends to follow this approach:
someButton.setActionCommand("mycommand");
someButton.addActionListener(listener);
--snip--
public void actionPerformed(ActionEvent event) {
String command = event.getActionCommand();
if (command.equals("mycommand"))
doThis();
else if (command.equals("someothercommand"))
doThat();
etc.
This seems kind of clunky to me - is there any benefit to this style of programming, or is it better to use Swing Actions?
Or are there different situations where the different approaches are better/worse?
IMO, it is better to use separate listeners for Actions.
That way you leave the delegating of what action should happen up to Swing. You don't have to compare Strings to decide what to do.
Having one huge ActionListener for more than one action feels like breaking the pattern to me.
From a design point of view, I think it is better to have one class to handle one specific action for a component as opposed to one class that is a "lets handle everything for all components here" type of design.
Also, if you use Action you can a) apply it to more than one component (e.g. a button and a menu item) b) call setEnable to enable/disable it for all components its attached to and c) Also use it to define various settings on the components its attached to (namely, the text label, the tooltip text, the accelerator key, icon, etc.). This last one is done via the putValue method and calling this method again will change the settings for all components its attached to.
Specifically, I would advise to subclass AbstractAction for your needs.
I know that's demo code but since you're working on this stuff I thought I'd mention that swing tends to be really repetitive if you're not careful.
Using Action classes tends to let you refactor better. In swing, one of the best ways to start is to ensure that NO strings are in your code. Nearly every "New" will be in a loop of some sort, reading from a dataset (Often the dataset is as simple as an array)--Once you start reading from a dataset like that, actions can help you a lot.
You use data to create your action, data to create your control, and data to associate the two--in this way you can end up very close to (or at) 0 lines of code for a new control.
Once you start programming this way and can see the patterns, it's at least as quick as the repetitive way and much less error prone.
its Useful if you have several buttons or components that perform the same action (ie. several exit buttons on the same page will use the same code)
Set them all to the same action command and they will all use the same code in the listener
JButton.addActionListener(this);
JButton2.addActionListener(this);
JButton.setActionCommand("exit");
JButton2.setActionCommand("exit");
public void ActionPerformed(ActionEvent e){
if(e.getActionCommand=="exit")
System.exit(0);
}
I've implemented my own event handler and added it to the selection model of the table:
table.getSelectionModel().addListSelectionListener(event);
And implemented the method for "event" (mentioned above):
public void valueChanged(ListSelectionEvent e) {
log.debug("value changed");
}
Unfortunately the event fires twice if I chance the selection and it doesn't seem possible to find the associated table, because e.getSource provides javax.swing.DefaultListSelectionModel.
Hence my questions are:
1) Why does it fire twice although the eventListener is only registered once?
2) How can I find the table for which the selection applies? The DefaultListSelectionModel doesn't seem to offer any getSource() or similar.
Many thanks!
Thanks Draemon..It Works fine....
Our Code
vMachinesTable.getSelectionModel().addListSelectionListener(new ListSelectionListener() {
public void valueChanged(ListSelectionEvent lse) {
if (!lse.getValueIsAdjusting()) {
System.out.println("Selection Changed");
}
}
});
Thanks By
TF Team
1) I think you'll find it fires once for de-selecting the old selection and once for selecting the new selection. If you log the details of the event you should see exactly what's going on. I can't remember the details, so perhaps this is wrong. Either way you should be able to call getValueIsAdjusting() on the event and only use the last one in the chain (ie when it returns false).
2) You shouldn't normally need to, but AFAIK the only way to do this is to create your Listener specifically for the table (ie pass the table to the constructor and remember it).
Since more than one JTable (or other component I'm guessing) can share the same selection model, it doesn't make sense to ask for the associated JTable from the event. This is the same reason that you can't retrieve a JTable from a TableModel. As Draemon suggests, store the reference to the JTable in (or make it accessible to) your listener class.