Zu Blöd für AWT - Frame/Canvas

[Capt'N Coax]

Hoi,

Ich bin offensichtlich zu blöd eine simpelste Java AWT Anwendung so zu basteln wie ich will.

Vorhaben:

Einfach schnell ein Fenster zu öffnen, in dem ein(e) Canvas in einer anderen Farbe als das Fenster angezeigt wird.

Allerdings "überschreibt" der(die)Canvas ständig das komplette Fenster mit seiner Background- Color. Oder ist genauso groß wie das Fenster, obwohl ganz anders definiert.

Am besten ich zeige euch mal den Code:

Datei 1: Main


import java.awt.*;

public class test
{
public static void main(String[] Args)
{
Gui gui=new Gui();
gui.setVisible(true);

}
}


Datei 2: Gui


import java.awt.*;

public class Gui extends Frame
{
Color c;
public Gui()
{
super("Hallo");
setBackground(c=new Color(0,0,0));
setSize(400,400);
setLocation(200,200);


Canvas1 c1=new Canvas1();
super.add(c1);

}
}


Datei 3: Canvas


import java.awt.*;

public class Canvas1 extends Canvas
{
Color c,d;
public Canvas1()
{
super();
setBackground(c=new Color(255,255,255));
setSize(20,20);
setLocation(20,20);
}

public void paint(Graphics g)
{
g.setColor(d=new Color(255,0,0));
g.fillRect(0,0,this.getSize().width,this.getSize().height);
}
}


Ich mein', simpler gehts doch nicht. Entweder schmeiss ich da die Veerbung total durch den Wind oder da stimmt was nicht. Ob ich Methode mit "super.bla" angebe oder nicht ist ja hier völlig egal, da eh nichts überschrieben wird.

Also nochmal:
Die Ausgabe zeigt ein weisses Fenster, sie sollte aber ein schwarzes Fenster zeigen, in dem sich ein kleineres rotes befindet (der canvas, mit Methode "paint" Rot überpinselt).

PLZ help, das GEHT MIR NÄMLICH ECHT SCHON SEIT 5 STUNDEN AUFM SACK! :(:(:(

[HellHorse]

Original geschrieben von Capt'N Coax
Oder ist genauso groß wie das Fenster, obwohl ganz anders definiert.

Genau das ist der Fall, denn für Grösse und Position ist der LayoutManager zuständig, per default ist das FlowLayout.
Hier eine kurzer Überblick:
http://java.sun.com/docs/books/tutorial/uiswing/layout/visual.html

Falls du das nicht willst, und es lieber selbst macht, kannst du das natürlich. Zuerst per setLayout(null) den LayoutManager ausschalten und dann mit setBounds(int, int, int, int) dahinter.

public class Gui extends Frame {
private Color c;

public Gui() {
super("Hallo");
this.addWindowListener(new WindowAdapter(){
public void windowClosing(WindowEvent e) {
setVisible(false);
dispose();
System.exit(0);
}
});
this.c = Color.BLACK;
this.setBackground(this.c);
this.setSize(400,400);
this.setLocation(200,200);
this.setLayout(null);

Canvas1 c1=new Canvas1();
this.add(c1);
}

private class Canvas1 extends Canvas {
private Color c,d;
public Canvas1(){
super();
this.c = Color.WHITE;
this.d = Color.RED;
this.setBackground(this.c);
this.setBounds(20, 20, 40, 40);
}

public void paint(Graphics g) {
g.setColor(this.d);
g.fillRect(0,0,this.getSize().width,this.getSize().height);
}
}

public static void main(String[] Args){
Gui gui=new Gui();
gui.setVisible(true);

}
}

[Capt'N Coax]

Danke, das scheint zu funktionieren. :)
5 Stunden verschwendet mit dem Kram, mal wieder sehr unnötig.

Setzt du prinzipiell vor Membervariablen den this- operator?
Nötig ist es ja an der Stelle IMO nicht.

Werde mal weiter frickeln und thx,
Coax

[HellHorse]

Original geschrieben von Capt'N Coax
Setzt du prinzipiell vor Membervariablen den this- operator?
Nötig ist es ja an der Stelle IMO nicht.

Ja.
"Nötig" ist es nur, wenn man eine Instanz- und eine lokale Variable bzw. Argument hat mit gleichem Namen.

[mithrandir]

Genau. Nötig ist es nur in diesen speziellen Fällen, allerdings ist es manchmal sehr hilfreich (vor allem bei Klassen die dann sehr umfangreich sind), wenn man auf den ersten Blick sieht, welche angesprochene Variable nun ein Klassenmember ist und welche nicht - zumindest ist das für mich so ; - )

Die beste Flexibilität (und den meisten Overhead natürlich) hat man IMO mit dem GridBagLayout, womit man sehr viel machen kann (auch viel Mist bauen natürlich). Aber IMO sind die LayoutManager auch jetzt noch für komplexe Anwendungen viel zu wenig mächtig und zu unflexibel - es gibt zwar einige Lösungen ausserhald der Standard-API, aber oft will man diese dann nur widerwillig einsetzen.

bye, mith

[Gast]

Ich hab mir angewöhnt ein m_ vor Membervariablen zu setzen, wenn der Code groß genug wird. Ist allerdings relativ selten der Fall.
Eine Zeit lang habe ich auch Typ- Identifier davor gesetzt, so dass eine Member Variable vom Typ int ungefähr so aussah:

int m_i_Blablubb;

Dann bekommt man aber Probleme sollte man versuchen den Code konsistent zu halten, BufferedReader wäre dann z.B. BR_xxx etc., das artet schnell aus ;).

Was ich absolut hasse wie die Pest sind 1-Buchstaben Vars, die kann man später noch nicht einmal ersetzen. Wird aber sehr oft genutzt, im sogenannten Kompakt-Code.
Viel Spaß an die Person die da n Monat später noch durchsteigen soll. Kommentiert wird da wohl auch nix, man weiß ja was man tut :D.

Naja, hat jeder seinen eigenen Stil.
Ich mit meinem miserablen Gedächtnis schreibe lieber ausführliche deutsche Variablennamen wenn die Umgebung es erlaubt. Hab zwar ob der Länge schon viel Kopfschütteln geerntet, wußte aber immer wo ich dran bin.

Die beste Flexibilität (und den meisten Overhead natürlich) hat man IMO mit dem GridBagLayout, womit man sehr viel machen kann (auch viel Mist bauen natürlich). Aber IMO sind die LayoutManager auch jetzt noch für komplexe Anwendungen viel zu wenig mächtig und zu unflexibel - es gibt zwar einige Lösungen ausserhald der Standard-API, aber oft will man diese dann nur widerwillig einsetzen.


Da meine Anwendung im wesentlichen auf 4 Canvas beruht, und nur 2 davon threadmäßig frameweise repaintet werden müssen, mache ich wenigstens die Ausrichtung im Hauptfenster selbst (eigener Layout- Manager).
Ich hab mich aber ehrlich gesagt noch nicht mit den Managern beschäftigt, seit HTML- Tabellendesign (schon was her, soll man ja auch nicht mehr tun) bin ich da wohl etwas oft "verbrannt" worden. Und gebranntes Kind...:stareup:

[Capt'N Coax]

/\

Explorer hat keine Kekse bekommen.
Das war natürlich ich.

[HellHorse]

Original geschrieben von Gast
Was ich absolut hasse wie die Pest sind 1-Buchstaben Vars,

Du meinst so wie die c's, und das d in deinem Code :naughty:
Original geschrieben von Gast
die kann man später noch nicht einmal ersetzen.

Rechtsclick -> Refactor -> Rename

[Capt'N Coax]

Original geschrieben von HellHorse
Du meinst so wie die c's, und das d in deinem Code :naughty:


Muhahah! Erwischt!
Red ich mich mal raus:
Das war auch nur ein billigst Beispiel Programm was nicht mehr exisitert. Der Korrekt- implementierte Code sieht anders aus, hätte hier aber vom wesentlichen abgelenkt.

Original geschrieben von HellHorse
Rechtsclick -> Refactor -> Rename

Wenn ich versuche eine 1-Variable Datei/en -weit zu ersetzen, bekomme ich spätestens dann Probleme wenn ich (um beim Beispiel zu bleiben) c in z.B. public oder irgendwelche anderen Wörter habe. Kommt c nur an einer Stelle vor brauche ich freilich nichts ersetzen, das kann ich auch von Hand ändern ;).

Bitte nicht von diesem BeispielCode auf meine "normale" Arbeit schliessen.
Hat das mit dem Herausreden geklappt oder glaubt mir trotzdem keiner?

Edit: Formatierung

[HellHorse]

Original geschrieben von Capt'N Coax
Wenn ich versuche eine 1-Variable Datei/en -weit zu ersetzen, bekomme ich spätestens dann Probleme wenn ich (um beim Beispiel zu bleiben) c in z.B. public oder irgendwelche anderen Wörter habe. Kommt c nur an einer Stelle vor brauche ich freilich nichts ersetzen, das kann ich auch von Hand ändern ;).

Ich sage nicht
Search -> Replace
sondern
Rechtsclick -> Refactor -> Rename

[Senior Sanchez]

Ich sage nicht
Search -> Replace
sondern
Rechtsclick -> Refactor -> Rename


Eben. Ne gute IDE wie der JBuilder oder Eclipse stellen entsprechende Refactoring Methoden zur Verfügung, die auch auf Sichtbarkeit und Referenzen achten ;)


mfg Senior Sanchez