OHLCSeries 'add' method invokes the ComparableObjectSeries class method 'add', which receives a parameter "notify" to indicate whether you want to notify listeners about the change.
My problem is that OHLCSeries 'add' method doesn't has that parameter, so I can't choose between notifying or not, and I need to be able to.
I've tried invoking the 'super' (ComparableObjectSeries) add method from OHLCSeries, but it is not visible.
Any idea on how could I choose when notify listeners and when not, when adding new items?
(I would like to avoid having to override the entire OHLCSeries class or extend it, hoping there is a easier way of doing it)
Since ComparableObjectSeries extends org.jfree.data.general.Series, I've thought on using this class method 'setNotify()' to activate/deactivate notifications to OHLCSeries listeners before invoking the 'add' method.
Even though this solution makes the trick, I'm still interested on how could it be done using a parameter on the 'add' method, directly from OHLCSeries class, so any idea is welcome.
Related
Is there a way to call a method from another class to the class where the run method is present (without creating the object of the class with the run method)? I would like to know how the method addMouseListeners() call my mouseClicked() method located in the class where the run method is present. Please answer.
I think you're asking about the callback pattern. Wiki has some information and examples you might be interested in.
In general, the callback pattern involves passing off an instance of a class which will have various methods on it called in response to some event. Your mouse listener is a callback class instance, and the container you passed it to is generating mouse events and passing them to your mouse listener.
I have created a method for getting the text from a selected radio button when I pass it the buttongroup it's in. I've been reading that helper/utility classes might not be the best idea because they can turn into god classes, which I can see happening after a while. Plus, I'm only adding one method and that method is very specific to buttons.
So my question is, is there a best way to add a method to a class that oracle made? I would like this method to always be available whenever I make a new project and use buttongroups.
Create a subclass that contains your new method.
Inheritance: http://docs.oracle.com/javase/tutorial/java/IandI/subclasses.html
Do you mean that you want to add methods to JRadioButton? You cannot do that. The typical way this is done is by extending JRadioButton, add the method and use that class everywhere.
When handling various events, my general policy has been to create a xxxHandler class like MouseHandler, WindowHandler, etc which extends its appropriate xxxAdapter class provided by Java.
I was just going over some other text about handling events and it says that whenever you extend any EventListener interface, say ActionListener, you must call the enableEvents(AWTEvent e) method in the constructor and call the super.processXXXEvent() whenever an event is generated.
I find this approach highly confusing. These methods have the access specifier as protected so I assume that these are for internal use only ?
What exactly are those methods for ?
Are they really needed for handling events ?
Do they offer any benefits over the usual actionPerformed(), mouseMoved(), etc where you add your code to handle the events in the method definition without calling any super methods?
Help needed. Simple words are highly appreciated rather than technical mumbo-jumbo.
What exactly are those methods for?
The processEvent() method filters the types of events that comes to it. The parameter to this method is of type AWTEvent type.
After filtering, this method calls the corresponding processXYZEvent() method which takes the corresponding event object.
For example, processMouseEvent(MouseEvent)
The processXYZEvent() method notifies the corresponding listeners about the event by passing the event object to the handler.
For example, processMouseEvent(MouseEvent) notifies the registered mouse listener(s).
The enableEvents() method decides what event(s) to give to the processEvent() method. This method cannot be overrided since it is final. However this can be accessed in the sub class of the Component class to decide what type of events that the component support.
Are they really needed for handling events ?
Their role is mentioned above. This means that they are needed for handling events because you can only handle an event when an event object is created and dispatched and those methods do this.
When I edit the quantity of an object in a list and the toString changes, how do I get the list to update with the new toString?
Example, when I change nodes in my JTree, I use nodeChanged(node) what do I do when I change a list item?
AbstractListModel#fireContentsChanged if you extend from AbstractListModel.
It is the same principle as for the JTree of your previous question. The AbstractListModel does not know when some internal property of your objects is changed. So when you make a change, you must call that particular method indicating the object is changed. The list model will fire the correct event which is received by the JList, which will update/repaint (whatever you want to call it).
Personally I prefer to create ListModels which are self-contained, e.g. if the objects you use fire events when they change the ListModel can listen for those changes and fire the appropriate events itself instead of having to call this method externally.
Edit
Just noticed that that particular method is protected, so you need to create the model as I suggested and you cannot call that method externally (which is a good thing)
List.updateUI() will do it, although I'm told this has some overhead.
I just learned (the hard way) that Java Components can only have one DropTarget. No sweat, I said, I'll just add another DropTargetListener to that DropTarget--only to discover that DropTargets can only have one DropTargetListener!
I have two DropTargetListeners that listen for very different events (one handles things being dragged and dropped within the component, the other handles things from outside the component). Must I combine them into one giant DropTargetListener, or is there an elegant way to keep them separate?
DropTarget is a unicast source, so you can add at most one DropTargetListener to it. I believe it should be a simple object that examines the source (inside/outside) of the thing being dropped and calls one of your DropTargetListeners depending on the result.
Edit: If you are hell bent on creating a "universal" solution, then you might try creating a wrapper event that passes method calls to the original event, but intercepts rejectDrop(), acceptDrop() (and maybe other methods that can cause trouble), then pass the wrapper to your listeners, until one accepts it. This assumes that the listeners recognize "good" events and act accordingly.
If you don't find a satisfactory solution, you could use the Composite Pattern to create a DropTargetListener that has a list of child DropTargetListeners. Whenever one of its methods are called, it would iterate over its list of listeners and invoke the same method. That would allow you to hand a single DropTargetListener to the Component but still have multiple DropTargetListeners called.