show JDialog every 30 seconds

Knute Johnson wrote:
> Lew wrote:
>> Knute Johnson wrote:
>>> Jim Janney wrote:
>>>> Anabolik <> writes:
>>>>
>>>>> 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.
>>>>
>>>
>>> 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.
>>
>
> 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.

--

Knute Johnson
email s/nospam/knute2009/

--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access

Knute Johnson

Knute Johnson wrote:
> 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.

--
Lew

Lew

On Wed, 4 Nov 2009 01:19:41 -0800 (PST), Anabolik <>
wrote, quoted or indirectly quoted someone who 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?

see http://mindprod.com/jgloss/timer.html
--
Roedy Green Canadian Mind Products
http://mindprod.com

An example (complete and annotated) is worth 1000 lines of BNF.

Roedy Green

Lew wrote:
> Knute Johnson wrote:
>> 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.
>

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 .

--

Knute Johnson
email s/nospam/knute2009/

--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access

Knute Johnson

Knute Johnson wrote:

> 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.

markspace

Knute Johnson wrote:
> Lew wrote:
>> Knute Johnson wrote:
>>> 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.
>>
>
> 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.

--
Lew

Lew

Lew wrote:
> Knute Johnson wrote:
>> Lew wrote:
>>> Knute Johnson wrote:
>>>> 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.
>>>
>>
>> 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.

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 .

--

Knute Johnson
email s/nospam/knute2009/

--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access

Knute Johnson

Knute Johnson <> writes:

> Jim Janney wrote:
>> Anabolik <> writes:
>>
>>> 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.
>>
>
> 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.../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.

--
Jim Janney

Jim Janney