Threads and a GUI

[Michael Powe]

Hello,

I have a simple GUI that runs some methods from a class that formerly
was part of a commandline application. Execution of the methods works
fine but sometimes freezes the UI until completion. In addition, I
start a logger when the application is loaded (GUI fires up), and the
logging seems to die before completing.

My thought is that the GUI freezes because the processing taking place
in the method is in the same thread as the GUI. I am a bit puzzled
about the logging, though. The file output stops in the middle of a
line, as though the logger exited before completing the output.

From what I've read, using threads in a GUI application is tricky, and
I'm ignorant of threads, anyway. So, I'm asking for confirmation that
my thought about the freeze is correct, and suggestions about what
might be happening with the logging and how I can "spin off" the
method processing safely.

If it matters, this application is starting and stopping Windows
services via "net start" and "net stop" system commands; and logging
the output.

Thanks.

mp

Here's the main class:

public class Main {

public static void main(String[] args) {

ControlServices.createLogger();

java.awt.EventQueue.invokeLater(new Runnable() {
public void run() {
RestartWt7UI ui = new RestartWt7UI();
ui.setSize(500,300);
ui.setVisible(true);
}
});


}

}

 

[=?ISO-8859-2?Q?Dra=BEen_Gemi=E6?=]

From what I've read, using threads in a GUI application is tricky, and

I'm ignorant of threads, anyway. So, I'm asking for confirmation that
my thought about the freeze is correct, and suggestions about what
might be happening with the logging and how I can "spin off" the
method processing safely.

If your application takes some considerable amount of time
to process something, the GUI will freeze until the processing is
finished.

You can start a thread from GUI application, but you won't be
able to wait for notification that the thread task is finished.
Simply because it will freeze the GUI again.

My advice is to run a thread from the GUI, pass it some reference
of your GUI classes and show a screen that asks user to wait a moment.
When the processing thread is finished it should move the GUI
to the next screen. That's why it needs a reference to some GUI classes.

As an illustration, I had a GUI application that does a lot of
processing. I start a thread and pass it a reference to the
CardLayout that contains different screen definitions of my
applications. hen the processing is finished, it uses a reference
to CardLayout instance to return to main menu.

DG

 

[Thomas Weidenfeller]

I have a simple GUI that runs some methods from a class that formerly
was part of a commandline application.

This is ugly. Retro-fitting an CLI application with a GUI is ugly,
because the CLI application typically has a completely different control
flow than what is needed for a GUI application.

Consider reworking at least the control flow from scratch.

sometimes freezes the UI

See Q3.1 and Q3.2 of the comp.lang.java.gui FAQ.

From what I've read, using threads in a GUI application is tricky,

It's not tricky. There are three simple things to take care of. See Q4.2
of the FAQ.

I'm ignorant of threads,

Well, that might be your main problem then.

how I can "spin off" the
method processing safely.

Learn about threads, learn the GUI's threading rules, and execute things
in separate threads - if needed.

/Thomas

 

[Michael Powe]

This is ugly. Retro-fitting an CLI application with a GUI is ugly,
because the CLI application typically has a completely different control
flow than what is needed for a GUI application.

Well, in this case there isn't any "control flow," as I am simply
calling some static methods which turn on or off certain Windows
services. This class was originally embedded in another application
and these methods _were_ used as part of a process, there.

One of the problems faced in this situation is that there appears to be
no documentation whatever on moving from a commandline application to a
GUI or "event-driven" one. I have several tools that I've written that
I would like to "transition" but I've put off having to figure it out
from scratch.

See Q3.1 and Q3.2 of the comp.lang.java.gui FAQ.

Thanks, I will.

It's not tricky. There are three simple things to take care of. See Q4.2
of the FAQ.

See page 275 of _Java Examples in a Nutshell, 3rd edition_. David
Flanagan doesn't agree with you.

Thanks for the references. I will follow up on them.

mp

 

[Michael Powe]

My advice is to run a thread from the GUI, pass it some reference
of your GUI classes and show a screen that asks user to wait a moment.
When the processing thread is finished it should move the GUI
to the next screen. That's why it needs a reference to some GUI classes.

As an illustration, I had a GUI application that does a lot of
processing. I start a thread and pass it a reference to the
CardLayout that contains different screen definitions of my
applications. hen the processing is finished, it uses a reference
to CardLayout instance to return to main menu.

Thank you for this idea, I will look into it. I understand what you
mean and I had not thought of this approach.

Thanks.

mp

 

[=?ISO-8859-2?Q?Dra=BEen_Gemi=E6?=]

Thank you for this idea, I will look into it. I understand what you

mean and I had not thought of this approach.

Neither had I, in the beginning

DG