That's a pleasure
Emma Sophia Jones wrote:. . . Thanks for the advice Campbell
No, repost soon, so we can see how you are getting on. Show us the new version of the circle class.
. . . repost at the next hurdle (or at the finish line!)
Horstmann (and Cornell in older editions) Core Java II has an example in where you alter an array and get Exceptions if you run multiple threads. Can't remember the page number or even the volume. Sorry. Ask again in about 15 hours and I can probably find that information.
Emma Sophia Jones wrote:. . . Why it will lead to errors wasn’t really made clear anywhere that I looked, most sources just said to take it on faith… so I’ll call this the mysterious multi-thread error)
Well done reading all that lot
. . . That’s why you have the SwingWorker class – to handle these time consuming operations while allowing the GUI to remain responsive.
Don't know. Sorry. I would have expected that too; what does it say in the documentation for repaint()? That isn't that helpful, but if you look at some of the overridings in lightweight subclasses, e.g. this, it says something about after other events have occurred, so that does sound like something queued on the EDT.
. . . A) The repaint() method I’m calling from the Ball class does something different to what I was expecting. My expectation is that this would queue a paint command in the EDT. Is it actually the case that this causes the JPanel to be updated directly? . . .
A Runnable won't run until you tell it to. You would have to write
B) The run() method for the ball is actually executing within the EDT. . . . B seems unlikely as I can resize the window etc . . .
Fred Kleinschmidt wrote:Also, when you do call repaint, you should use the method with no parameters.
By calling the repaint with x,y,width, and height as parameters, you are adding that rectangle to the region that will get repainted; other parts of the panel may not get redrawn. This method is usually used by the system when it determines that part of the panel needs to be redrawn due to it becoming newly exposed (because some other window that was covering it has gone away, and backing store is not capable of restoring the view). It should not be used if the contents of the JPanel have actually changed.
Using repaint with no arguments does seem like the easier option but the (x, y, w, h) version of the method was recommended in the Oracle docs
Cay S Horstmann and Gary Cornell, Core Java 9/e vol I‑Fundamentals, Redwood Shores CA: Oracle/Pearson 2013, chapter 14.11 pages 909‑925. I don't think that information was in the older edition I have, for Java5, and am not sure about the newer edition (10th) for Java8.
Yesterday, I wrote:. . . Can't remember the page number or even the volume. Sorry. Ask again in about 15 hours and I can probably find that information.
The current version scales up to about 1024 balls without a hit in performance
I have found my 10th edition:
Yesterday, I wrote:. . . not sure about the newer edition (10th) for Java8.
Campbell Ritchie wrote:Since paintShape takes a Graphics parameter, can you simply use a method reference?
I am pretty sure that is what I did.
Darryl Burke wrote:. . . how would you invoke it from a Timer's ActionListener? Rather, the Timer would simply repaint() the panel and paintComponent(...) would take care of the rest.
There is another action listener not shown here to close the app after a certain time. It works if I change the method to this:-It even works if I spell dleay correctly.
The class Campbell tried it out with wrote:
Campbell Ritchie wrote:I am pretty sure that is what I did.
Campbell Ritchie wrote: