File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Swing / AWT / SWT and the fly likes How does setVisible(true) work? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "How does setVisible(true) work?" Watch "How does setVisible(true) work?" New topic

How does setVisible(true) work?

John Smith
Ranch Hand

Joined: Jul 20, 2001
Posts: 84
Hi All,
I have a class which can either open a JDialog or a native Windows application via JNI. The determination of which one to open is inside the overridden setVisible method. When I call super.setVisible(true), everything works as it's supposed to, e.g., the parent window and all the windows behind the newly visible JDialog continue to repaint themselves, even though setVisible() doesn't return (blocking inside the event dispatching thread!?) until the window is closed. How does this occur? Is there a way to reproduce this behavior when showing a native application?
As of now, when the native window is opened, the method doesn't return until the window is closed, but the Java parent window behind the native window doesn't repaint itself. Does anyone know of a way I can get this to work?
I've tried putting the method that shows the native window in the construct method of the SwingWorker class, but then setVisible returns immediately, instead of blocking until the window is closed. Any help would be appreciated.
[ August 11, 2002: Message edited by: Randy Gordon ]
Mahesh swami

Joined: Aug 13, 2002
Posts: 26
I think you can write the code of opening the Native window in run method of a RUnnable object and then call SwingUtilities.invokeLater(Runnable).I think this should work.
John Smith
Ranch Hand

Joined: Jul 20, 2001
Posts: 84
Yes, I did something similar. Actually, I used the SwingWorker construct and finish methods. The problem with these (and invokeLater) is that they cause the setVisible method to return right away, instead of blocking.
I got around this by passing an ActionListener to my overriden setVisible method, which calls the actionPerformed method when the window is closed. Previously, the code inside the actionPerformed method appeared immediately following the call to setVisible, but since setVisible was returning right away it wasn't working. It should have only been executed after the window was closed. I can enforce this by encapsulating the code in an ActionListener.
This works like I want, but passing an ActionListener to a setVisible method is a little weird. And I still don't understand how windows can repaint themselves even though setVisible(true) blocks. It gets called in the event-dispatching thread for heaven's sake!
I agree. Here's the link:
subject: How does setVisible(true) work?
It's not a secret anymore!