1

I have three classes. One is a worker class that does all the hard work but doesn't display anything. The other two are GUI classes one of which calls the other. The one that calls the second GUI class has the worker class open.

The first GUI calls the second with this method:

protected void openAdd() {

        AddPet add = new AddPet(ADD_PROMPT, FIELDS, DATE_PROMPT);
        add.setVisible(true);
    }

The second GUI class is used to get information from the user that is used in the worker class but, as I already have the worker class open in the first GUI I don't want to open it again and I want to use some of the information in the first GUI.

What I need to do is pass that information in the second GUI back to the first GUI so that it can work with it and pass it to the open worker class.

How do I do this?

EDIT: I think the best option would be to call a method in the first GUI from the second GUI but I don't know if this is even possible.

  • 1
    M-V-C is the way to go. Use one model for all, and have both GUI's display their views based on the state of the model. – Hovercraft Full Of Eels Jan 12 '15 at 00:48
  • 1
    You could pass a reference of the "worker" class to the second GUI class...Try and reduce the exposure of your classes, unless the second GUI class actually needs to know about the first GUI class, I'd avoid exposing it, as this couples the code together, which you don't want and exposes the first GUI class to potentially unwanted modifications – MadProgrammer Jan 12 '15 at 00:48
  • `"I think the best option would be to call a method in the first GUI from the second GUI but I don't know if this is even possible."` -- "GUI"'s are objects, pure and simple. Any object can call a public method of another object if it has a proper reference. Again, I still believe that your best option is to use M-V-C structure, but as in most things, the devil exists in the details. If you need more specific help, then you first, please tell us more of the details and show us your pertinent code, preferably as a [minimal example program or MCVE](http://stackoverflow.com/help/mcve). – Hovercraft Full Of Eels Jan 12 '15 at 01:08
  • If the second window is a modal dialog such as a modal JDialog or JOptionPane, your job of passing information is **much** easier as shown in my answere [here](http://stackoverflow.com/a/7017147/522444). – Hovercraft Full Of Eels Jan 12 '15 at 01:13

1 Answers1

1

On second thought, it looks like your second window is being used essentially as a dialog off of the first window, and that you're using it for user data entry and little else. If so, then make sure that the second window is not a JFrame but is rather a modal JDialog. If so, then it will block user interaction with the first window when it's open, and extracting information out of it will be easy, since you're know exactly when the user is done with it, since program flow will resume in the first GUI immediately following your code that sets the second window visibile.

e.g.,

// in this example, AddPet is a modal JDialog, not a JFrame
protected void openAdd() {
    // I'm passing *this* into the constructor, so it can be used ...
    //    ... in the JDialog super constructor
    AddPet add = new AddPet(this, ADD_PROMPT, FIELDS, DATE_PROMPT);
    add.setVisible(true);

    // code starts here immediately after the AddPet modal dialog is no longer visible
    // so you can extract information from the class easy:

    String petName = add.getPetName(); // I know you don't use these exact methods
    String petBreed = add.getPetBreed(); // but they're just a "for instance" type of code
    // ... etc

}

....

Hovercraft Full Of Eels
  • 283,665
  • 25
  • 256
  • 373
  • Yes. After reading the link you supplied it's obvious that I should have been using JDialog rather than JFrame. Now looking at how to convert my code. –  Jan 12 '15 at 01:41
  • 2
    @DracoTBastard: to be quite honest, I rarely have code that extends JFrame or JDialog. Most of my GUI or "view" code creates JPanels or extends JPanels. These can then be placed into JFrames or JDialogs, or JTabbedPanes, or swapped via CardLayouts, wherever needed. I believe that this has greatly increase the flexibility of my GUI coding. – Hovercraft Full Of Eels Jan 12 '15 at 01:47