0

My application's main frame starts a JFrame thread:

IBM1622GUI cardReadPunchGUI = new IBM1622GUI(); // instantiate
Thread cardReadPunchThread = new Thread(cardReadPunchGUI); // alloc thread
cardReadPunchThread.start(); // call thread's run() method

Later, the main frame needs to "destroy" IBM1622GUI (as part of "taking a peripheral offline"), and still later, to reinstantiate it - presumably using the same procedure as above. What should the main frame do to basically return to the state prior to when the IBM1622GUI was first instantiated?

EDIT - I should probably mention that IBM1622GUI, the JFrame class, is being developed with NetBeans as a "Swing GUI Form", and thus there are certain limitations on what edits I can make to the source code.

Chap
  • 3,649
  • 2
  • 46
  • 84
  • We don't have enough information on your code. We know nothing of what the main frame "state" is. – toto2 Aug 03 '11 at 00:35
  • It's fully operational, visible - just sitting there having its event handlers driven by the EDT. Is that sufficient info? I didn't write the main frame - it's 12 years old and uses AWT (no Swing). – Chap Aug 03 '11 at 00:54
  • I stupidly thought "main frame" referred to a simulated IBM main frame computer... – toto2 Aug 03 '11 at 01:04
  • I guess `cardReadPunchGUI.dispose(); cardReadPunchGUI = new IBM1622GUI();` should do what you want. However it's not clear if some of the "state" of the first cardReadPunchGUI might still be present in some other objects. – toto2 Aug 03 '11 at 01:07
  • @toto: Hah! Actually, the entire app *is* a simulation of a very old IBM "mainframe." But here I'm referring to the first, primary window, which shows the console of an IBM1620. Turning on the power switch causes the allocation of a faceless "CPU" thread and a 1622 Card Read/Punch unit (a separate JFrame). Turning *off* the power switch should dispose of those items. – Chap Aug 03 '11 at 01:18

2 Answers2

2

Read this

You should use this style to init a JFrame.

IBM1622GUI cardReadPunchGUI = null;
SwingUtilities.invokeLater(new Runnable() {
    public void run() {
        cardReadPunchGUI = new IBM1622GUI();
    }
});

When you want to close the JFrame, here is already the question with answers

(Edit by Chap: the linked SO thread is very long and meandering, but it boils down to simply using cardReadPunchGUI.dispose(). This does, in fact, answer my question satisfactorily, and I'd like to give credit for this answer but I would also like for this note to be included.)

Community
  • 1
  • 1
timaschew
  • 16,254
  • 6
  • 61
  • 78
  • Both of the links that you included appear to deal with "main" threads, and the process of terminating the *application*. I don't want to quit the Application, but rather close a secondary window and later reopen it. If that answer is contained in the links, it's not obvious to me :-) – Chap Aug 03 '11 at 00:38
  • Its not only for main threads. The 2nd link contains the solution with [dispose](http://download.oracle.com/javase/1.4.2/docs/api/java/awt/Window.html#dispose%28%29) Why you don't use it? – timaschew Aug 03 '11 at 00:50
  • I believe the `new IBM1622GUI()` is actually started from the "main frame", so it's already in the EDT. – toto2 Aug 03 '11 at 01:03
  • Edited answer to highlight the fact that dispose() was the answer to my question. – Chap Aug 03 '11 at 18:19
2

It sounds like you want to suspend() and resume() the cardReadPunchThread. Although those methods are deprecated, you can use the approach outlined in Java Thread Primitive Deprecation as a way to control the model. Alternatively, an instance of javax.swing.Timer is slightly easier to stop() and start(), as suggested here. On the view side, setVisible() may work, depending on your design.

Community
  • 1
  • 1
trashgod
  • 203,806
  • 29
  • 246
  • 1,045
  • It's easier for me to design it if I can simply "roll back" to an earlier state. I don't know if that's always going to be feasible in this multi-threaded, interdependent GUI universe, but it's where I'd like to start :-) Of course, if performance there becomes an issue, that's a different story. – Chap Aug 03 '11 at 04:33
  • @Chap create only one JFrame, re-use that, don't create lots of JFrames on fly, is pretty possible that from here coming you performancies problems – mKorbel Aug 03 '11 at 06:38