Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Issues with the setting up of Actionlisteners for JButtons  RSS feed

 
John Eipe
Ranch Hand
Posts: 215
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

This is a Swing program that continuously alters the color in a circle when "start" is clicked. And it stops when "stop" is clicked. I have given below the full code listing (not sure if this was necessary but i think it could involve both Syntactical and logical errors)
I believe something is wrong with the listener class. Is this methodology correct?

 
John Eipe
Ranch Hand
Posts: 215
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This program when run displays the frame correctly but throws an exception
-Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
when "start" is clicked.
 
Rob Camick
Ranch Hand
Posts: 2800
15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
but throws an exception -Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException


Well, when it throws the Exception is also tells you the line of code that is causing the problem. So figure out which variable is null and why it is null.

ColorsGo.this.start.setEnabled(false);
...
panel.repaint();


Why do you reference variables in two different ways? Be consistent in your code. Being lazy I would use the second approach.

Is this methodology correct?


For animation it is better to use a Swing Timer. This way when the Timer fires you know your code will be executed in the Event Dispatch Thread.
 
Fred Hamilton
Ranch Hand
Posts: 684
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am not comfortable with having so much of the program logic inside the event handler (actionPerformed method). I'm not blaming your null pointer on this, though.

I would be more inclined to have an infinite loop in my main class, perhaps a while loop in a threaded run method that monitors a boolean variable and executes the loop when ever that Boolean variable is true. Then my event handler for the JButtons would simply set the boolean variable to true or false. I probably wouldn't bother with a separate class for the event handler, but that's just me.

Perhaps this is all just style, six of one half a dozen of the other, I'm not sure. It is also not clear to me how using a Swing Timer fits in with what I am saying.

edited for clarity.
 
Rob Camick
Ranch Hand
Posts: 2800
15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would be more inclined to have an infinite loop in my main class


There is rarely a need for an infinite loop in event driven programming, which is what a GUI is all about.

I probably wouldn't bother with a separate class for the event handler


Tend to agree, I would probably just use annonymouse inner classes. At any rate there is no reason to create two of the same class. The class can be shared by both buttons.

It is also not clear to me how using a Swing Timer fits in with what I am saying.


When using a Timer:

- the Start button would simply start the Timer (1 line of code)
- the Stop button would simply stop the Timer (1 line of code)
- when the Timer fires you tell the panel to repaint itslef (1 line of code).

All the code is executed in the EDT so the GUI works properly. The current code is causing the EDT to sleep which means the GUI can't repaint itself.
 
Fred Hamilton
Ranch Hand
Posts: 684
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rob Camick wrote:
I would be more inclined to have an infinite loop in my main class


There is rarely a need for an infinite loop in event driven programming, which is what a GUI is all about.




ok noted. It looks here like Swing Timer eliminates the need for an infinite loop. I shall rephrase. Here is a program design where an event is used to stop and start an infinte loop. In situations where an infinite loop is appropriate, and where events are appropriate to stop and start the loop, then I'd be more inclined not to have the loop in the event handler.

Anyways, thanks for the tips about swing timer, I'll add that to my ever growing list of things to look into more deeply. One final thing which seems very relevant here, and which I don't fully understand is, why is it preferable to have code execute in the event dispatching thread. Without spending too much time explaining, would you use the same sort of design for a game such as Pong? Or maybe an animation with multiple sprites moving around?
 
Rob Camick
Ranch Hand
Posts: 2800
15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
why is it preferable to have code execute in the event dispatching thread


It is not just preferable, it is a requirement of Swing that any code that updates the state of a Swing component should exeute in the EDT. Read the section from the Swing tutorial on
Concurrency in Swing.
 
Fred Hamilton
Ranch Hand
Posts: 684
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rob Camick wrote:
why is it preferable to have code execute in the event dispatching thread


It is not just preferable, it is a requirement of Swing that any code that updates the state of a Swing component should exeute in the EDT. Read the section from the Swing tutorial on
Concurrency in Swing.


Your use of the word "should" tells me a lot. Anyways, thanks, I'm well aware of the Java Tutorial, one more thing for the todo list. I was more interested in what you had to say on the matter. I often find the distillations I get from people on this forum very useful.

But it's been good from a learning perspective, so thanks again.
 
Campbell Ritchie
Marshal
Posts: 55715
163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And a tiny point: you have ;flag == true; in your loop heading. Never write == true and never write == false. They are poor style and prone to nasty errors if you mistakenly write = for ==.
You write ; flag; or ; !flag; assuming flag is a boolean.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!