Can a jPanel's background be made to blink off and on
JT
ability to blink... ie. flash off and on every 5 seconds for 2 minutes?
Andrew Thompson
>or is there an attribute/property of a jPanel that will give it the
>ability to blink... ie. flash off and on every 5 seconds for 2 minutes?
No.
--
Andrew Thompson
http://www.athompson.info/andrew/
Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-gui/200706/1
Andrew Thompson
Sub: Can a jPanel's background be made to blink off and on
1) Is that a question?
2) Are you referring to a JPanel, or some class that is
not in the J2SE?
In any case, it is possible to *extend* JPanel (or jPanel,
I am guessing) to provide a method that will do that.
JT
> In any case, it is possible to *extend* JPanel (or jPanel,
> I am guessing) to provide a method that will do that.
Sometimes the fonts on my machine make jPanel and JPanel look the same,
especially if it's late at night. But, to answer your question, I am
looking for a way to make my "flashing green" light flash. I looked in
the API but could not find anything which would do what I wanted, so I
thought someone might have done something similar in the past and would
be willing to share their ideas.
Andrew Thompson
JT wrote:
>> In any case, it is possible to *extend* JPanel (or jPanel,
>> I am guessing) to provide a method that will do that.
>
>Sometimes the fonts on my machine make jPanel and JPanel look the same,
>especially if it's late at night.
Please either get a better font, or better excuses..
>...But, to answer your question, I am
>looking for a way to make my "flashing green" light flash. I looked in
>the API but could not find anything which would do what I wanted,
I find that completely unsurprising. I cannot imagine
it is often that a GUI requires *flashing* panels.
(muses) Perhaps slightly more common than a
requirement for panels with polka dots, but not
much so.
>...so I
>thought someone might have done something similar in the past and would
>be willing to share their ideas.
I haven't, but a slight tweak of my earlier code should
point *a* way to go about it. Note that this is still using
AWT (just because I'm feeling perverse) and uses the
centred circle (rather than the background) to change
color. Further, no logic is performed to ensure that only
one signal is flashing at any instant.
Adapt as needed ('batteries not included').
<sscce>
import java.awt.*;
import java.awt.event.*;
class TrafficLight {
public static void main(String[] args) {
Frame f = new Frame("Lights");
Panel lightboard = new Panel( new GridLayout(0,1) );
lightboard.add( new TrafficSignal(Color.green) );
lightboard.add( new TrafficSignal(Color.yellow) );
lightboard.add( new TrafficSignal(Color.red) );
f.add( lightboard );
f.pack();
f.addWindowListener( new WindowAdapter() {
public void windowClosing(WindowEvent we) {
System.exit(0);
}
} );
f.setLocationRelativeTo(null);
f.setVisible(true);
}
}
class TrafficSignal extends Panel implements Runnable {
Color on;
int radius = 55;
int border = 10;
boolean active;
boolean flashing = false;
long startFlash = 0;
/** It should flash for 10 seconds. */
long lengthFlash = 10000;
TrafficSignal(Color color) {
on = color;
active = true;
this.addMouseListener( new MouseAdapter() {
public void mouseClicked(MouseEvent me) {
setFlashing(true);
}
} );
Thread t = new Thread(this);
t.start();
}
public Dimension getPreferredSize() {
int size = (radius+border)*2;
return new Dimension( size, size );
}
public void run() {
while (true) {
if ( flashing ) {
active = !active;
repaint();
if ( System.currentTimeMillis()-startFlash>lengthFlash ) {
flashing = false;
}
}
try {
Thread.sleep(400);
} catch (InterruptedException ie) {
// wake and continue
}
}
}
public void setFlashing(boolean flash) {
flashing = flash;
startFlash = System.currentTimeMillis();
}
public void paint(Graphics g) {
g.setColor( Color.black );
g.fillRect(0,0,getWidth(),getHeight());
if (active) {
g.setColor( on );
} else {
g.setColor( on.darker().darker().darker() );
}
g.fillOval( border,border,2*radius,2*radius );
}
}
</sscce>
HTH
--
Andrew Thompson
http://www.athompson.info/andrew/
Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-gui/200706/1
---
* Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24
Philipp
Andrew Thompson a |-crit :
Shouldn't the GUI be updated from the EDT thread? How would this be done?
If I understand your SSCCE correctly, the frame is shown from the "main"
thread. And the blinking is updated from your "TrafficLight" thread.
Thanks for your insight
Phil
Andrew Thompson
>Andrew Thompson a écrit :
>>>> In any case, it is possible to *extend* JPanel (or jPanel,
>>>> I am guessing) to provide a method that will do that.
Please refrain from 'full-quoting'. Selective trimming
of earlier posts does wonders. Note that my current
web interface to usenet automatically trims most text
before I get to reply.
>Shouldn't the GUI be updated from the EDT thread? How would this be done?
Yes and no.
The 'rule' is that UI updates outside the EDT should
be updated using invokeLater, something like..
<snippet>
public void run() {
while (true) {
if ( flashing ) {
active = !active;
Runnable r = new Runnable(){
public void run(){
repaint();
}
};
EventQueue.invokeLater(r);
if ( System.currentTimeMillis()-startFlash>lengthFlash ) {
flashing = false;
}
}
try {
Thread.sleep(400);
} catch (InterruptedException ie) {
// wake and continue
}
}
}
</snippet>
I say 'rule' because I have never observed any GUI
problems to be caused by ignoring it.
(shrugs) YMMV.
[ Waits for the invokeLater devotees to jump in with
lots of long words and remonstrations - with no code
that can back up the claims. ]
--
Philipp
> Philipp wrote:
>> Andrew Thompson a écrit :
>>>>> In any case, it is possible to *extend* JPanel (or jPanel,
>>>>> I am guessing) to provide a method that will do that.
> ..
>
> Yes and no.
> Runnable r = new Runnable(){
> public void run(){
> repaint();
> }
> };
> EventQueue.invokeLater(r);
If the flashing frequency is very high, does the invokeLater guarantee a
more responsive GUI (ie will some repaints be discarded if there are 10
waiting in the queue?).
JT
>
> public void setFlashing(boolean flash) {
> flashing = flash;
> startFlash = System.currentTimeMillis();
> }
So perhaps I can drop a centered circle on to my JPanel and use your
code to make it blink? Thanks for your insight.
BTW - the whole JPanel, jPanel thing... I wasn't paying attention to
what I was typing... hence the mistake.
BTW2 - I am using Swing for my app, so if I use your idea, I'll be
mixing Swing and AWT. Is this true?
Philipp
> Andrew Thompson wrote:
>>
>> public void setFlashing(boolean flash) {
>> flashing = flash;
>> startFlash = System.currentTimeMillis();
>> }
>
> So perhaps I can drop a centered circle on to my JPanel and use your
> code to make it blink?
Probably you'd better use setBackground(Color) on the JPanel and repaint
it as in Andrews code.
Knute Johnson
The repaint() method need not be called from the EDT as it is only a
scheduler. The paint will actually get done on the EDT even though you
call repaint() from some other thread.
--
Knute Johnson
email s/nospam/knute/
Philipp
> The repaint() method need not be called from the EDT as it is only a
> scheduler. The paint will actually get done on the EDT even though you
> call repaint() from some other thread.
Could you recommend some free tutorial to read about how to build swing
GUI applications with threads?
I want to program a feature where the user moves a JSlider which after
some calculations shows a result in the GUI depending on the slider's
position. It works now fully in the EDT but lags a lot.
This is because the slider creates continously events and each event
must be calculated and shown.
What would be the optimal architecture for such a construct. How can I
drop the processing of events if the GUI lags more than a certain time
behind the slider position.
Phil
Tom Hawtin
> Philipp wrote:
>
>> Shouldn't the GUI be updated from the EDT thread? How would this be done?
> I say 'rule' because I have never observed any GUI
> problems to be caused by ignoring it.
>
> (shrugs) YMMV.
>
> [ Waits for the invokeLater devotees to jump in with
> lots of long words and remonstrations - with no code
> that can back up the claims. ]
Somethings to back up my claims:
o Using early access Java 1.5, jEdit deadlocked due to updating Swing
components off the EDT.
o Using early access Java 1.6, jEdit deadlocked due to updating Swing
components off the EDT.
o FindBugs gui2 often deadlocked on single threaded hardware, although
this was trying to do some stuff on the EDT and screwing up. For a
program designed to find bad code, FindBugs is very badly written.
Writing code that shows threading issues is highly unrewarding (top tip:
develop your demonstration with multi-threaded hardware, then backport
to single-threaded).
It is probably true that the vast majority of threading bugs don't
actually occur. Stuff that occurs in constructors often doesn't have the
old happens-before action going on, but never ever fails. I'd put money
on there being more threading bugs in the Sun Java library than it has
classes.
However, it's much easier all round if you strive to write code that
obviously has no errors (rather than code that has no obvious errors).
It'd make my job far less dull if people did that.
Tom Hawtin
Tom Hawtin
> Andrew Thompson a écrit :
>> class TrafficSignal extends Panel implements Runnable {
>> boolean active;
>> public void run() {
>> while (true) {
>> if ( flashing ) {
>> active = !active;
>> repaint();
> Shouldn't the GUI be updated from the EDT thread? How would this be done?
The code is actually using AWT without Swing (for some reason). AWT is
supposedly thread-safe (it isn't, but it attempts to be).
If this were a Swing application it would still conform to the rules.
repaint is allowed to be called from non-EDT threads.
Even though active is not protected by being volatile or having locked
access, it should pick up a happens-before from the event dispatch.
However, I could make lots of criticisms of this code:
o It uses AWT instead of Swing...
o It appears to needlessly subclass Panel, where Canvas or JComponent
would be more appropriate.
o There is no reason for the same class to implement Runnable as
extends Panel. <controversial>I think Java would be better without
interfaces.</controversial>
o The original problem didn't need Panel to be subclasses at all.
o The thread goes on until the program exits.
o Using javax.swing.Timer would be more convenient (and run actions on
the EDT). o Missing private and final keywords.
Tom Hawtin
JT
Knute Johnson
> Knute Johnson a écrit :
>> The repaint() method need not be called from the EDT as it is only a
>> scheduler. The paint will actually get done on the EDT even though
>> you call repaint() from some other thread.
>
> Could you recommend some free tutorial to read about how to build swing
> GUI applications with threads?
Look at the Java Tutorial on Sun's web site. That is the best source
for how to write Swing code. Just because you can call repaint()
outside the EDT doesn't mean that you can update a Swing GUI outside of
the EDT.
> I want to program a feature where the user moves a JSlider which after
> some calculations shows a result in the GUI depending on the slider's
> position. It works now fully in the EDT but lags a lot.
>
> This is because the slider creates continously events and each event
> must be calculated and shown.
>
> What would be the optimal architecture for such a construct. How can I
> drop the processing of events if the GUI lags more than a certain time
> behind the slider position.
>
> Phil
You need to take a look at JSlider.getValueIsAdjusting(). With this
method you can test in your ChangeListener whether the slider is moving.
If it is, don't bother to update your GUI until it stops. Or make
occaisional updates while it is moving.
If you want to continue this discussion, start a new thread.