show JDialog every 30 seconds

A

Anabolik

For JDialog it exists the function toFront. How to implement the logic
to show the JDialog in the front of desktop every 30 seconds?
 
R

RedGrittyBrick

Anabolik said:
For JDialog it exists the function toFront. How to implement the logic
to show the JDialog in the front of desktop every 30 seconds?

Maybe you could use a java.util.Timer.

This feature is likely to be very annoying for users isn't it? There are
more conventional and platform-specific means of drawing the user's
attention to applications that are awaiting their attention. In the case
of Windows that might be blinking the application's icon in the tool bar.
 
A

Anabolik

I made in Timer. Here the code:

int delay = 30000;
Timer timer = new Timer();
timer.schedule(new TimerTask() {
public void run() {
myDialog.toFront();
myDialog.repaint();}
}, delay);

but my dialog did not appear on the front of all windows.
 
L

Lew

Anabolik said:
I found the solution.

And thank you ever so much for sharing it with us instead of treating us like
your private, unpaid support staff.

This is a discussion group, not a help desk.
 
J

Jim Janney

Anabolik said:
I made in Timer. Here the code:

int delay = 30000;
Timer timer = new Timer();
timer.schedule(new TimerTask() {
public void run() {
myDialog.toFront();
myDialog.repaint();}
}, delay);

but my dialog did not appear on the front of all windows.

Your code is running on the wrong thread. See SwingUtilities.invokeLater.
 
K

Knute Johnson

Jim said:
Your code is running on the wrong thread. See SwingUtilities.invokeLater.

Probably not necessary. repaint() certainly not and toFront() is a
method of Window and probably doesn't need to be called on the EDT.
 
L

Lew

Knute said:
Probably not necessary. repaint() certainly not and toFront() is a
method of Window and probably doesn't need to be called on the EDT.

Why would it not need to be called on the EDT?

There isn't anything in the Javadocs to indicate that Window is thread safe.
 
K

Knute Johnson

Lew said:
Why would it not need to be called on the EDT?

There isn't anything in the Javadocs to indicate that Window is thread
safe.

Window is an AWT component. No requirement to use the EDT on AWT
components that I know of.
 
K

Knute Johnson

Knute said:
Window is an AWT component. No requirement to use the EDT on AWT
components that I know of.

I'm not really sure the toFront() and toBack() is the way to get this to
work. toFront() only puts the window in front of other windows in the
same VM. The setAlwaysOnTop() works fine on my XP box though.
 
L

Lew

Knute said:
Window is an AWT component. No requirement to use the EDT on AWT
components that I know of.

From what I've read, all GUIs, even those not of Java, really need to be
single-threaded to work right. I've been under the impression that this
applies to AWT, too.

I need strong evidence that AWT is thread safe, not evidence that it isn't.
 
K

Knute Johnson

Lew said:
From what I've read, all GUIs, even those not of Java, really need to
be single-threaded to work right. I've been under the impression that
this applies to AWT, too.

I need strong evidence that AWT is thread safe, not evidence that it isn't.

You won't find a single example on Sun's web site of AWT GUI creation on
the EDT. You won't find any mention of AWT components needing to be
created on the EDT in the docs or that AWT isn't thread safe.

It is hard to prove the negative when there is no mention of the
positive, or is it the other way round?

But find me a mention in some Sun doc, tutorial or anywhere that says
that it isn't and I will quietly fade into the background :).
 
M

markspace

Knute said:
Window is an AWT component. No requirement to use the EDT on AWT
components that I know of.


Window is an AWT component, but JDialog is a Swing component. And it's
objects which need to be synchronized, not method calls. If AWT doesn't
deal with Swings synchronization properly (and I don't see how it could)
there's still a need for thread safety on the caller's part.

I don't seen any methods at all marked as thread safe in JDialog's docs.
I think all of it's methods, including inherited ones, should be
called only on the EDT.
 
L

Lew

Knute said:
You won't find a single example on Sun's web site of AWT GUI creation on
the EDT. You won't find any mention of AWT components needing to be
created on the EDT in the docs or that AWT isn't thread safe.

It is hard to prove the negative when there is no mention of the
positive, or is it the other way round?

But find me a mention in some Sun doc, tutorial or anywhere that says
that it isn't and I will quietly fade into the background :).

You're the one assuming an unprovable negative.

The literature says that all GUIs share the need to run GUI actions on the GUI
thread. You assume safety where danger might lurk without evidence that you
are correct. I assume danger with some evidence that it might exist. Absent
an authoritative assertion of safety, prudence is the superior strategy.

The burden of proof is on the assertion of safety.
 
K

Knute Johnson

Lew said:
You're the one assuming an unprovable negative.

The literature says that all GUIs share the need to run GUI actions on
the GUI thread. You assume safety where danger might lurk without
evidence that you are correct. I assume danger with some evidence that
it might exist. Absent an authoritative assertion of safety, prudence
is the superior strategy.

The burden of proof is on the assertion of safety.

So you say but Sun doesn't and they do for Swing. Sun never shows
invokeLater() on AWT code examples and they do for Swing. Sun never
mentions thread safety issues with AWT and they do for Swing. I think
you are assuming there are alligators in the swamp without getting in to
look :).
 
J

Jim Janney

Knute Johnson said:
Probably not necessary. repaint() certainly not and toFront() is a
method of Window and probably doesn't need to be called on the EDT.

Looking at

http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html

I find

The following JComponent methods are safe to call from any thread:
repaint(), revalidate(), and invalidate(). The repaint() and
revalidate() methods queue requests for the event-dispatching
thread to call paint() and validate(), respectively. The
invalidate() method just marks a component and all of its direct
ancestors as requiring validation.

so yes, repaint() is safe. A quick search doesn't turn up anything
one way or the other for toFront(). Call me old-fashioned, but
"probably safe" doesn't seem like a good basis for making coding
decisions.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,831
Latest member
HealthSmartketoReviews

Latest Threads

Top