Swing Gültigkeitsbereich (Sichtbarkeit) von Instanzvariablen (Swing-widgets)

[tsitra]

Hallo allerseits,

es handelt sich wohl um ein Problem bezüglich Gültigkeitsbereich (Sichtbarkeit), also Zugreifbarkeit von Instanzvariablen.

Ausgegangen bin ich von einer Java-Tutorial Anwendung...JTabbedPaneDemo
die ich etwas erweitert habe, was bisher auch recht gut lief.

In einem einzelnen Tab meiner JTabbedPaneDemo10 ist eine kleine DB-Anwendung.
Ein insert von einem Person-Datensatz in eine MySQL-DB.
Das klappt auch gut.

Dann kam eine Idee: Vor dem Insert nochmal eine Sicherheitsabfrage
"Wollen Sie wirklich einen neuen Person-Datensatz in die DB einfügen?"
(Dafür wurde dann "class Dialog5 extends JDialog implements ActionListener{..}." dazu genommen.)

Ensprechend will ich dann innerhalb der
"public void actionPerformed(ActionEvent ev)" des Dialog5
auf die aktuell belegten Textfelder für den Person-Datensatz zugreifen.

Und das klappt nicht! Sie sind, egal was ich aktuell eintrage, mit dem initialen
Wert belegt, weil sie offenbar zu dem initial erzeugten JTabbedPaneDemo10-Objekt gehören.

Wie komme ich aus der "actionPerformed(ActionEvent ev)" des Dialog5
an die AKTUELLEN Textfelder-Inhalte aus JTabbedPaneDemo10?


Programmaufbau:
Innerhalb einer Quelldatei JTabbedPaneDemo10.java habe ich eine class für ein Dialog-Fenster
und eine class JTabbedPaneDemo10 für einen Jframe mit JTabbedPane.
In class JTabbedPaneDemo10 ist die main(...).

class Dialog5 extends JDialog implements ActionListener{...

und eine class  mit der main(...)

public class JTabbedPaneDemo10 extends JPanel implements ActionListener{...

usw. usw.

 private static void createAndShowGUI(){
        //Create and set up the window.
        JFrame frame = new JFrame("JTabbedPaneDemo10");
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        // Add content to the window.
        frame.add(objJTPane, BorderLayout.CENTER);
        frame.add(new JTabbedPaneDemo10(), BorderLayout.CENTER);
        //Display the window.
        frame.pack();
        frame.setVisible(true);
    }
    
    public static void main(String[] args) {
        //Schedule a job for the event dispatch thread:
        //creating and showing this application's GUI.
        SwingUtilities.invokeLater(new Runnable(){
            public void run(){
                //Turn off metal's use of bold fonts
		UIManager.put("swing.boldMetal", Boolean.FALSE);
		createAndShowGUI();
            }
        });
    }

Ich vermute, dass ich eventuell Fehler im grundsätzlichen Aufbau gemacht habe.
Vielleicht darf der gewünschte Dialog5 nur als irgendeine Inner class
innerhalb class JTabbedPaneDemo10 implementiert werden?!

Ich danke für verständliche Hinweise.


Viele Grüße
tsitra

 

[Marco13]

Die Lösung ist ganz einfach:

import java.awt.*;

usw usw

:joke:

Mehr code könnte helfen. Aber es klingt nach dem, was erschreckend Oft gefragt wird:

class KlasseA {}

class KlasseB_SollKlasseAVerwenden
{
    // Hilfe, wie kommt KlasseA hier her?
}

->

class KlasseA {}

class KlasseB_SollKlasseAVerwenden
{
    private KlasseA a;
    public void setA(KlasseA a) { this.a = a; } // So..
}

Und dann an einer passenden Stelle "b.setA(a)" aufrufen. SEHR pragmatisch, meistens führt das, wenn man es "immer" so macht, zu häßlichsten Verklüngelungen, aber die Alternativen zu erklären macht vermutlich keinen Sinn, solange die Frage in dieser Form gestellt wurde.

 

[tsitra]

Danke Marco, der Tipp hat sehr schnell zu dem geführt was ich beabsichtigte.

Die Lösung ist ganz einfach:

Ja. ...etwas peinlich.
Ich ahnte schon, dass es simpel ist. Kenne ich eigentlich recht gut als "HAS-A" Beziehung.

Aber da mein Vertrauen selbst in sehr gute Java-Lehrbücher (z.B. von K. Sierra und B.Bates)
zwar selten, aber manchmal doch, einen Dämpfer bekommen, habe ich lieber mal direkt hier gefragt.

Und dann an einer passenden Stelle "b.setA(a)" aufrufen. SEHR pragmatisch, meistens führt das, wenn man es "immer" so macht, zu häßlichsten Verklüngelungen,

Ich habe mal gehört, dass das tight coupling genannt wird und vermieden werden soll, oder?

aber die Alternativen zu erklären macht vermutlich keinen Sinn, solange die Frage in dieser Form gestellt wurde.

Klingt so als würdest Du mir wenig zutrauen.

Viele Grüße
tsitra

 

[Marco13]

Das "ganz einfach" bezog sich auf das "usw usw", wo ggf. wichtige Codeteile hätten stehen können
(BTW: Ich traue jedem wenig zu. (Auch mir.) ).
Aber ja, das wäre "Tight Coupling", genaugenommen das Tighteste, das es gibt (abgesehen von Vererbung). Wie schlimm das in diesem Fall ist, ist wegen Codemangels schwer zu sagen. Wenn dort nur ein spzieller Dialog angezeigt werden soll, kann es sein, dass die Klassen ohnehin und prinzipbedingt (schon auf "semantischer" Ebene) so direkt miteinander verbunden sind, dass eine weitere Referenz (also dieses HAS-A) da kein Problem darstellt, sondern eben so ist. Wenn man aber z.B. später
- Von der Hauptklasse aus evtl. einen anderen Bestätigungsdialog verwenden will oder
- Den Bestätigungsdialog auch für Bestätigungen an anderer Stelle verwenden will
könnte man sich überlegen, wie man die beiden mehr entkoppeln und damit leichter austauschbar bzw. wiederverwandbar machen könnte.

 

[tsitra]

Hallo Marco, und Danke, noch für diese Antwort.

Ich werde das Thema ordnungshalber jetzt mal als erledigt kennzeichnen.

Gruß
tsitra

 

[GUI-Programmer]

Alternative:
Anstatt wie von Marco13 beschrieben eine Methode zu erstellen, die die Instanz weitergibt, könntest du dies bereits im Konstruktor von Dialog5 erledigen:

//...
private JTabbedPaneDemo10 tbd10;
public Dialog(JTabbedPaneDemo10 tbd10) {
    this.tbd10 = tbd10;
}

 

[Gast2]

Bei Dialogen empfiehlt sich auch eine einfache Factory. Diese könnte man bei Bedarf z.B. auch konfigurieren um das Aussehen der Dialoge zu ändern.

Man öffnet dann den Dialog nur noch per Factory. Ich habe z.B. im Framework eine Alternative zum OptionPane Factory. Zwecks schönerem layout (Mindestgrößen der Buttons ect.)