Für eine Übung habe ich ein Testprogramm geschrieben (Code anbei),
welches auf Komponenten von Swing (JFrame, JPanel und JScrollBar)
beruht. Geschrieben mit Eclipse 2019 auf dem Mac und als Jar-File
exportiert.
Unter OSX sieht die GUI genau so aus, wie es gewollt ist und wie es m.E.
auch im Code steht. Starte ich das gleiche Programm jedoch unter Windows
10, sieht es bereits nach dem Start nicht exakt aus und fasst man dann
einen der Scrollbalken an, erscheinen in der oberen linken Ecke
"Fragmente" des selben.
Wer Lust und Zeit hat, bitte mal auf den Code sehen und mir mitteilen,
wo der Fehler ist. Bitte keine Antworten, die eine völlig andere
Herangehensweise an die Programmierung vorschlagen, ich möchte unbedingt
wissen, wo genau der Fehler in konkret diesem Code ist. Danke.
Nachtrag: Was mich auch wundert: Es sollte doch genügen, wenn ich z.B.:
import javax.swing.*;
schreibe. Aber es gibt immer wieder einzelne Klassen aus Swing, die
müssen unbedingt explitit aufgerufen werden, sinst "kotzt" Eclipse.
Warum? Bug oder unverstandenes Feature? Bei awt ist das noch viel
schlimmer ...
JavaNeuling schrieb:> Nachtrag: Was mich auch wundert: Es sollte doch genügen, wenn ich z.B.:>> import javax.swing.*;
Das ist NICHT rekursiv.
Dein eigentliches Problem:
1
publicvoidpaint(Graphicsg)
2
{
3
g.setColor(newColor(cr,cg,cb));
4
g.fillRect(10,10,380,30);
5
}
Du zeichnest hier nur ein Teil des Panel.
Mach auf der 1. Zeile noch super.paint(g);
Der würde den Hintergrund zeichnen.
Jetzt wird nur dieses Rechteck gezeichnet, alles andere ist einfach
Zufall.
Und Zufall ist Betriebsystem Abhängig.
mfg Andreas
Andreas B. schrieb:> Dein eigentliches Problem: public void paint(Graphics g)> {> g.setColor(new Color(cr,cg,cb));> g.fillRect(10, 10, 380, 30);> }>> Du zeichnest hier nur ein Teil des Panel.> Mach auf der 1. Zeile noch super.paint(g);
Hmmm ... OK, danke. Das Einfügen dieser Zeile verhindert, dass ich den
"Unfall" in der Ecke zu sehen bekomme, weil er schnell übermalt wird -
soweit so gut.
Aber wieso werden dort oben überhaupt Fragmente der Scrollbars
hingezeichnet? Die "kleben" doch ganz eindeutig an sPanel, ganz
definiert mit SetBounds ... ?
JavaNeuling schrieb:> Aber wieso werden dort oben überhaupt Fragmente der Scrollbars> hingezeichnet? Die "kleben" doch ganz eindeutig an sPanel, ganz> definiert mit SetBounds ... ?
Dein LayoutManger ist auf null gesetzt, da musst du dann selber z.t. für
repaints sorgen, evt. auf den EDT warten,.... Das lässt man deshalb
immer bleiben ausser du machst Animationen,... wo das eher wieder stört
wenn der dazwischen funkt.
Wenn du das ohne LM machst musst du selber für den Repaint sorgen,
teilweise spielt es glaube ich noch eine Rolle wie der Background der
Komponente gesetzt ist, opaque oder nicht, da hat man auch entspr.
Effekte wobei das bei dir der Nulllayout ist.
Franko S. schrieb:> JavaNeuling schrieb:>> Aber wieso werden dort oben überhaupt Fragmente der Scrollbars>> hingezeichnet? Die "kleben" doch ganz eindeutig an sPanel, ganz>> definiert mit SetBounds ... ?>> Dein LayoutManger ist auf null gesetzt, da musst du dann selber z.t. für> repaints sorgen, evt. auf den EDT warten,.... Das lässt man deshalb> immer bleiben ausser du machst Animationen,... wo das eher wieder stört> wenn der dazwischen funkt.
Den Layoumanager habe ich auf Null gesetzt, weil der sonst bestimmt, wo
die Controls stehen und setBounds() bzw. setLocation() für die Panele
keine Wirkung haben. Gibt es da eine "Zwischenlösung"?
JavaNeuling schrieb:> Den Layoumanager habe ich auf Null gesetzt, weil der sonst bestimmt, wo> die Controls stehen und setBounds() bzw. setLocation() für die Panele> keine Wirkung haben. Gibt es da eine "Zwischenlösung"?
Du kannst einen eignen LayoutManager machen, für Spezialfälle ist das
oft recht angenehm.
Aber grundsätzlich sind die Layoutmanager schon das richtige.
Denk mal z.B. dran, das jemand schlecht sieht, und die Schrift doppelt
so gross eingestellt hat wie du.
Dann passt der Text nicht mehr in den Label. Bei Layoutmanger passiert
das nicht, da wird halt das Fenster grosser...