• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • paul wheaton
  • Ron McLeod
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Piet Souris
Bartenders:

threads for GUI and command-line

 
Ranch Hand
Posts: 255
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a command-line program and I'm trying to give it a GUI gradually. So, what I have now is a point in the program where the command line is waiting for user input, and at the same time, there is a button on the GUI that is supposed to do something when pushed. I experimented a little, pushing the button, and entering things on the command line. I keep getting this long list of error messages, and the GUI frame becomes transparent, and other weird things happen. Is it a no-no to have a program waiting for a command from the command line and to have an active button waiting to be pushed at the same time?
I looked at the error messages and noticed the word "thread" in many of the messages. Do you have to make two separate threads when you are doing what I am trying to do?
I have another idea about how to do this program. Start out at the command line with the computer program waiting for commands. One of the commands is a command to go to the GUI. That command will also end the program (that is, finish running through the "main" method) and then display the GUI. That way, the program is all finished and you just have the buttons on the GUI active. Then, when you have the GUI window, one of the buttons is a command to go back to command-line input. That command will also make the GUI window invisible, and call a method which asks for user input on the command line. I think if I do the program that way, it will work better because you won't have an active button and an active command line at the same time. What do you think?
 
Ranch Hand
Posts: 99
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Have you thought about putting a text field in your gui that accepts commands?

That way you can have both gui and command line functionality.
 
Kevin Tysen
Ranch Hand
Posts: 255
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you. I'm working on what you suggested. I'm discovering that to make a GUI you have to think and write code completely in the reverse direction, compared to command-line.
 
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I looked at the error messages and noticed the word "thread" in many of the messages. Do you have to make two separate threads when you are doing what I am trying to do?


No, you do not have to make two separate threads. Although the way I understand it, java actually creates two threads behind the scenes. The error messages tell you which thread the error occured in. Every java program has a main thread and with GUI's there is an event dispatch thread.

As a matter of fact, there is a new way to create JFrame's that you are supposed to use, which prevents problems inherent in the old way. The new way uses the event dispatch thread and it's kind of ugly.

old way:


The new way involves two steps:

1) Put the code that creates a window in a method.
2) Attach the method to the event dispatch thread.

Yep, the snippet beginning:

new Runnable...

is an anonymous inner class. Good luck to any beginners trying to understand what that is.

See: http://java.sun.com/docs/books/tutorial/uiswing/learn/example1.html
[ October 13, 2006: Message edited by: sven studde ]
 
Kevin Tysen
Ranch Hand
Posts: 255
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you. I have a question about the pack method and setVisible method of the frame object. I made a frame and added a panel to it and then made it visible. Then I added buttons to the panel. But when I ran the program the buttons did not appear. But when I changed the size of the window, the buttons appeared. To make the buttons appear, do you have to use setVisible or pack (or both) after you add buttons? What does the pack method do?
 
sven studde
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Thank you. I have a question about the pack method


See here:

The pack method sizes the frame so that all its contents are at or above their preferred sizes. An alternative to pack is to establish a frame's size explicitly by calling setSize or setBounds (which also sets the frame's location). In general, using pack is preferable to calling setSize, since pack leaves the frame's layout manager in charge of the frame's size, and layout managers are good at adjusting to platform dependencies and other factors that affect component size.

...set the frame's location .. it's easy to do so using either the setLocationRelativeTo or setLocation method. For example, the following code centers a frame onscreen:

frame.setLocationRelativeTo(null);


So, it looks like I used pack() incorrectly because I used setBounds() previously to set the location and size of the window. I assume calling pack() subsequent to calling setBounds() causes pack() to override setBounds(). That would explain some weird things I was seeing with my window's size not reacting to changes I made with setBounds().

If you use pack() instead of setBounds() to determine the size of the window, then the issue is how do you set the window's location, which setBounds() does additionally. The quote says you can use one of the setLocation() methods.

setVisible method of the frame object


As I understand it, when you create a window it is invisible, and therefore you can choose when to display it. setVisible(true) makes it visible.

Then I added buttons to the panel. But when I ran the program the buttons did not appear. But when I changed the size of the window, the buttons appeared.


When you resize a window, the window repaints itself, so it sounds like you are having trouble getting the window to paint itself on startup. That may be one of the problems that is fixed by using the new method to display windows. In any case, post the code for the briefest example you can come up with that demonstrates the error, and then we can take a look at it.

By the way, in the new method:

instead of:

javax.swing.SwingUtilities.invokeLater(...

you can write:

SwingUtilities.invokeLater(...

since you are going to be importing javax.swing.* for almost all GUI's.
[ October 16, 2006: Message edited by: sven studde ]
 
Kevin Tysen
Ranch Hand
Posts: 255
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you. Here is what I have now.


What I want to do is have the frame and the panel visible all the time, and then add buttons to and subtract buttons from the panel. It seems that when I add a button to the panel, it doesn't appear right away, so I need to have some kind of command to make the button appear.
 
Ranch Hand
Posts: 802
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I dont know if this is practical or not,

but you could have a java.util.TimerTask running a while loop in
the background that waits for messages to be input to the command line,
and the 'timertask' acts as a Thread, so it doesn't affect your main thread.

Justin..

so you would make a Timer like so




so in the main you would ask the initial question with 'y'
and then you would schedule the timer..



this is a perdy cool utility, I think so atleast...

someone please correct if wrong or inefficient...

Justin Fox
[ October 16, 2006: Message edited by: Justin Fox ]
 
reply
    Bookmark Topic Watch Topic
  • New Topic