Nachträglich Swing-Elemente in JFrame erzeugen

[skummy]

Hallo Forum,


im Moment erzeuge ich meine GUI-Fenster komfortabel über den Netbeans-GUI-Builder. Jedoch habe ich noch keine Möglichkeit gefunden, wie ich nachträglich irgendwelche Labels, Buttons usw. auf den JFrame erzeugen kann, wenn bestimmte Benutzeraktionen (Klick auf Button) ausgeführt werden.

Ist das irgendwie möglich? Ansonsten würde Netbeans einen ja da schon ganz schön einschränken...!


Danke und Tschau

 

[Marco13]

Kommt drauf an. Eigentlich ist das ganz einfach:

class SomeFrame extends JFrame
{
    void init()
    {
        getContentPane().setLayout(new GridLayout(0,1));
        getContentPane().add(new JLabel("Hallo"));
    }

    // Später
    void addSomething()
    {
        getContentPane().add(new JLabel("Welt"));
        validate();
    }
}

Allerdings neigen solche GUI-Builder dazu, Code zu generieren, den man kaum noch verstehen kann und will. Es KÖNNTE also schwierig werden, die Stelle zu finden, wo man da was einfügen kann...

 

[skummy]

Hmmm...also für ein einfaches JFrame erzeugt Netbeans beispielsweise folgenden Code:

    private void initComponents() {

        setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE);

        javax.swing.GroupLayout layout = new javax.swing.GroupLayout(getContentPane());
        getContentPane().setLayout(layout);
        layout.setHorizontalGroup(
            layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)
            .addGap(0, 400, Short.MAX_VALUE)
        );
        layout.setVerticalGroup(
            layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)
            .addGap(0, 300, Short.MAX_VALUE)
        );

        pack();
    }

Wenn ich dann sowas machen will (Keine Ahnung wo das validate() hinkommt. Funktionieren tuts bei beiden nicht.):

    public static void main(String args[]) {
        java.awt.EventQueue.invokeLater(new Runnable() {
            public void run() {
               JButton jButton1 = new JButton("Hallo");
               FrameDlg dlg = new FrameDlg();    
               dlg.getContentPane().add(jButton1);
                                
               dlg.validate();
               dlg.setVisible(true);
               dlg.validate();
                
            }
        });
    }

wird kein Button erzeugt.

Eigentlich müsstes es doch aber auf diese Weise funktionieren, oder?


Bye
Sandro

 

[Marco13]

Ja, genau das meinte ich mit unverstehbarem Code - wenn ich sehe, das da manchmal für "GroupLayout"-Konstrukte rauskommen :autsch: In diesem Fall besonders albern, wenn in dem Frame noch nichts drin ist.... Eine Möglichkeit wäre, die Components, die man "eigentlich" in den Frame packen will, stattdessen in ein JPanel zu legen. DIESES JPanel kann man dann z.B. "von Hand" der ContentPane des Frames hinzufügen, und dort dann später z.B. einen Button drunterklemmen.... Nur mit einem "frame.getContentPane().add(button)" ist es im Moment leider nicht getan: Er muss ja wissen, WO und WIE er den Button einfügen soll...

 

[skummy]

Ohoh...irgendwie hab ich deinen letzten Post nicht richtig verstanden.

Du meinst, die "festen" Elemente auf ein JPanel packen? Und das was ich später hinzufügen will...halt irgendwie anders.

Bin ich denn der einzigste, der bis jetzt sowas machen wollte? Irgendwie kann ich mir das nicht vorstellen, dass das, was ich vorhabe, so kompliziert ist...! Oder macht man sowas grundsätzlich gar nicht?

 

[Marco13]

Naja - das ist eben einer der Gründe, warum manche Leute (ich) auf solche GUI-Builder verzichten: Man legt ein, zwei Buttons in einen Frame, und was rauskommt, sind 20 Zeilen Code mit ineinander geschachtelten GroupLayout-Aufrufen, die keiner mehr versteht, und keiner mehr vernünftig ändern kann - und WENN man was ändert, muss man damit rechnen, dass der GUI-Builder es nachher nicht mehr versteht, oder schlicht und einfach mit den überschreibt, was er kennt.

Wie auch immer: Bisher hattest du sowas wie

    private void initComponents() {

        setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE);

        javax.swing.GroupLayout layout = new javax.swing.GroupLayout(getContentPane()); //-------- getContentPane()!!!
        getContentPane().setLayout(layout);
        layout.setHorizontalGroup(
            layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)
            .addGap(0, 400, Short.MAX_VALUE)
        );
        layout.setVerticalGroup(
            layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)
            .addGap(0, 300, Short.MAX_VALUE)
        );
        getConentPane().add(button); //-------------------------------------------------------- oder so...

        pack();
    }

Das könnte man jetzt per Hand zu sowas umbauen

    private void initComponents() {

        JPanel panel = new JPanel();
        this.getContentPane().setLayout(new BorderLayout());

        //------------- Wie vorher, aber getContentPane() ersetzt durch das panel
        setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE);

        javax.swing.GroupLayout layout = new javax.swing.GroupLayout(panel); //-------- JPanel!
        getContentPane().setLayout(layout);
        layout.setHorizontalGroup(
            layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)
            .addGap(0, 400, Short.MAX_VALUE)
        );
        layout.setVerticalGroup(
            layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)
            .addGap(0, 300, Short.MAX_VALUE)
        );
        panel.add(button); //-------------------------------------------------------- oder so...
        //------------- Wie vorher, aber getContentPane() ersetzt durch das panel


        getContentPane().add(panel, BorderLayout.CENTER);
        pack();
    }

und später dann so eine Methode aufrufen wie

    private void add()
    {
        getContentPane().add(new JLabel("Label"), BorderLayout.SOUTH);
        validate();
    }

"Besser" (oder einfacher) wäre es, wenn man im GUI-Builder zuerst zwei Panels einfügt: Ins erste Panel kommt alles, was "eigentlich" in den Frame sollte. Das zweite Panel bleibt leer. Dann kann man später die neuen Components ins zweite Panel einfügen, ohne den eigentlich vom GUI-Builder gebauten Code groß verändern zu müssen....

 

[Guest]

OK, danke für deine Hilfe. Sieht so aus als müsste man sich dafür ganz schön verbiegen.

Ich hab jetzt einfach mal versucht Netbeans einen anderes Layout verwenden zu lassen. Beim Null-Layout generiert der Builder sowas:

    private void initComponents() {

        jButton1 = new javax.swing.JButton();

        setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE);
        setBounds(new java.awt.Rectangle(40, 0, 400, 300));
        setMinimumSize(new java.awt.Dimension(500, 500));
        getContentPane().setLayout(null);

        jButton1.setText("jButton1");
        getContentPane().add(jButton1);
        jButton1.setBounds(40, 170, 75, 23);

        pack();
    }

Sieht doch schon weit übersichtlicher aus, oder? Ich denke damit kann ich mein Problem auf einfachere Art und Weise lösen.

Stellt sich nur noch die Frage warum Netbeans ein anderes Layout verwendet, wo keiner durch den Code durchsteigt. Kennst du da eventuell Vor- und Nachteile? Besonders bezüglich Geschwindigkeit und Speichernutzung?


Tschau
Sandro

 

[Lim_Dul]

Ein Null-Layout verwendet man nicht. Man zerhaut sich damit jegliche Anpassungsfähigkeit der Fenster ans Vergößeren/Verkleinern/Schriftgrößen etc.

 

[Marco13]

Ja, besser wäre es, dem NetBeans zu sagen, dass er BorderLayout, GridLayout und BoxLayout verwenden soll. GroupLayout ist außerdem NetBeans-Spezifisch, d.h. du wirst den Code dann nicht ohne weiteres mit einer anderen IDE compilieren können.

Gründe, warum NetBeans das GroupLayout verwendet? Hm. Da könnte ich nur spekulieren. Das überlasse ich anderen.

 

[skummy]

Schade...und das gleiche gilt bestimmt dann auch fürs Netbeans-eigene Absolute-Layout, oder?

Schon komisch: Einfache Layouts wo jeder durchblickt sollte man nicht verwenden. Andere Layouts sind wiederrum schwer zu erlernen, womit man sich eines GUI-Builders bedient. Dieser erzeugt dann Code, den kein Mensch versteht... :shock:

Auch im Internet habe ich kein tolles Swing-GUI-Tutorial gesehen, dass einfach erklärt, wie man auch "komplizierte" Benutzeroberflächen erstellen und vor allen Dingen auch komfortabel pflegen kann.


Tschau
Sandro

 

[Gast]

Ein "Trick", den ich manchmal verwende, ist:

Die Buttons, die du später hinzufügen willst, einfach schon von Anfang an in die GUI mit dem Builder einfügen und fertig platzieren.

Während der Initialisierung einfach .setVisible(false) nutzen und sie erst dann sichtbar machen, wenn du sie haben möchtest.

Ein Haken an der Sache ist natürlich, dass du vorher schon wissen musst wieviele es sind, wohin sie kommen usw.

 

[Marco13]

Complicator's gloves - man könnte postulieren, dass solche GUI-Designer einfach nicht für sich verändernde GUIs gedacht sind.... Naja.

 

[GambaJo]

Ehrlich gesagt, bin ich auch mit den Möglichkeiten, die man zum GUI-Erstellen so hat, egal ob NB oder Eclipse, nicht sonderlich zufrieden.

Netbeans bietet einen GUI-Builder, der aber nicht immer so funktioniert, wie man sich das wünscht. Die Ergebnisse in der Entwicklung sehen oft anders aus, als wenn man die Applikation ausführt. Es gibt auch oft Unterschiede innerhalb der selben Applikation zwischen den Betriebssystemen (bei gleichem L&F). Die Layouts können einen in den Wahnsinn treiben.

Eclipse läuft bei mir nicht so richtig stabil. Den Visual Editor konnte ich bisher nicht erfolgreich installieren, immer fehlt irgendwas. Und alles zu Fuß machen finde ich irgendwie rückschrittlich. Mag ja sein, dass man so viel Kontrolle hat, aber ich bin mir sicher, dass der GUI-Builder besseren Code generiert, als ich, ein unerfahrener User, schreiben würde. Und bei komplexeren GUIs ist man alleine mit der GUI schon sehr lange beschäftigt, bis die mal halbwegs so ist, wie man es braucht. Nachträgliche Änderungen ziehen relativ großen Aufwand nach sich.

Aus meiner Sicht ist das alles nicht so das Gelbe vom Ei.

 

[byte]

Ein Null-Layout verwendet man nicht. Man zerhaut sich damit jegliche Anpassungsfähigkeit der Fenster ans Vergößeren/Verkleinern/Schriftgrößen etc.

Null-Layout ist schon nützlich, wenn man das Layouting per Hand programmieren will. Die bestehenden LayoutManager decken nicht alles ab.

 

[Michael...]

Ein Null-Layout verwendet man nicht. Man zerhaut sich damit jegliche Anpassungsfähigkeit der Fenster ans Vergößeren/Verkleinern/Schriftgrößen etc.

Null-Layout ist schon nützlich, wenn man das Layouting per Hand programmieren will. Die bestehenden LayoutManager decken nicht alles ab.

Ich hatte noch nie das Bedürfnis ein Null-Layout zu verwenden, halte ich persönlich auch für recht gefährlich. Wenn ich ein eigenes Layout nötige schreibe ich mir einen eigenen LayoutManager, ist normaler Weise kein grosser Aufwand. Teilweise mache ich das auch, obwohl ich mit einem GridBagLayout das gleiche erzielen könnte.

 

[Lim_Dul]

Ich habe das Null-Layout auch schon verwendet, so ist es nicht.

Nur ist das aber bei fast jeder Regel so, dass es tatsächlich Ausnahmefälle gibt, wo man gegen sie verstossen kann. Aber man kann einem Anfänger schlecht sagen "Null-Layout verwendet man nicht, außer in Ausnahmefällen."

Erstmal muss man verstehen, warum man es nicht verwendet. Dann und frühestens dann kann man sich entscheiden es zu verwenden. Solange man das aber nicht verstanden ist, sollte man auch keine Ausnahmen machen.

 

[byte]

Ich hatte noch nie das Bedürfnis ein Null-Layout zu verwenden, halte ich persönlich auch für recht gefährlich. Wenn ich ein eigenes Layout nötige schreibe ich mir einen eigenen LayoutManager, ist normaler Weise kein grosser Aufwand. Teilweise mache ich das auch, obwohl ich mit einem GridBagLayout das gleiche erzielen könnte.

Was ist daran gefährlich, wenn ich einen ComponentListener registriere, der "on resize" meine Resize-Logik aufruft (die Du extra in einem Custom LayoutManager kaspelst)? Ein eigener LayoutManager macht imo nur Sinn, wenn man ihn an mehreren Stellen wiederverwenden möchte. Das trifft bei mir aber i.d.R. nicht zu, wenn der Bedarf für eigenes Layouting besteht.

 

[Michael...]

gefährlich war vielleicht ein bisschen übertrieben;-)

ComponentListener registriere, der "on resize" meine Resize-Logik aufruft

Das ist quasi das gleiche was auch im LayoutManager passiert.
Du sparst Dir einen LayoutManager und ich spare mir einen ComponentListener, ist wahrscheinlich gehupft wie gedupft

 

[skummy]

@byto:

Quasi eine onResize-Implementation bauen, die die Position der Elemente einfach beim Verändern der Größe des Frames entsprechend anpasst?