[QUOTE=Zombiepriester]
Haupt-Panel an dem auch der Maus-Listener hängt:
@Override
public void mousePressed(MouseEvent arg0) {
dragged = true;
Rectangle cursor = new Rectangle(arg0.getX(), arg0.getY(), 1, 1);
if(cursor.intersects(comp.getRect())){//comp ist Instanz der Klasse Comp ist dem Panel schon hinzugefügt
draggedComp = comp;
}
}
@Override
public void mouseReleased(MouseEvent arg0) {
dragged = false;
draggedComp = null;
}
@Override
public void mouseDragged(MouseEvent me){
mouseMoved(me);
}
@Override
public void mouseMoved(MouseEvent me){
if(dragged){
draggedComp.setPos(new Point(
me.getX()-draggedComp.breite/2,me.getY()-draggedComp.höhe/2));
revalidate();
}
}
```[/QUOTE]
Wieso hast du den Code im Hauptpanel??
Das ist weder Objektorientiert, noch irgendwie schön...
Hast du mal den Code von mir oder SlaterB ausprobiert?
Und wieso hast du Breite und Höhe nochmal extra als Variablen, JComponent hat schon width und height???
Die Methode setPos ist doch equivalent zu der bereits bestehenden setLocation, oder??
und getRect ist 100% equivalent zu getBounds...
Warum so?
(Korrigier mich bitte wenn das spezielle Gründe hat die ich so nicht sehen kann(oder zu doof bin :D))
eines der angenehmeren Probleme, von einem gewissen Standpunkt aus,
überlege und verfolge Schritt für Schritt, was zwischen deinem Hauptprogramm und dem KSKB liegt,
gehe nochmal ins Hauptprogramm und überlege, was du dort streichst,
alles außer der Komponente und dem Layout darüber bis zum JFrame sollte keine Rolle spielen, nur das streichen,
aber diesen naheliegenden Gedanken hast du wohl auch
notfalls entsprechend längeres Programm posten,
eins ist jedenfalls klar: wenn das KSKB geht, dann kann dir fast unmöglich mit Standardwissen von anderne geholfen werden,
dieses zielt ja nur auf Standardprogramme hin, die dann auch funktionieren, wie du dir eindrucksvoll selbst gezeigt hast,
raten was sonst noch beliebiges Problem sein könnte ist dann mächtig vage
Schreib dir zur uebung ein programm, das durch den ordner dieses projekts laueft, jede .jav datei nimmt, die package deklarationen entfernt, sonstige parameter die nicht sein duerfen, ich glaube jede klasse muss public static gemacht werdem und so weiter, und letzten endes alles in eine datei schreibt. Dann poste die hier ^^
*** Edit ***
Schreib dir quasi einen LskbMaker. Das ist wirklich eine gute uebung ^^
Danke für den Tipp mit dem LSKB-Maker, dank des LSKB´s hab ich den Fehler gefunden.Es war ein Thread, der im Hintergrund immer läuft.Ich habs so gemacht, dass ich während des draggens diesen Thread anhalte und jetzt ruckelt es nicht mehr.
Um es mal ganz deutlich zu sagen: Worin glaubst du liegt der Unterschied zwischen MouseMoved und MouseDragged? Das ist nämlich rein zufällig nicht nur eine Sache von wegen der Mausknöpfe, sondern auch eine Sache des Aufrufs durch den EDT. Kurz gesagt mit
public void mouseDragged(MouseEvent me){
mouseMoved(me);
}```schiesst du dir unter Umständen (ganz gewiss sogar, wenn der Listener an der Component hängt, die gedragged wird) ganz schön ins Bein, weil dadurch mouseMoved 2 mal aufgerufen wird. Einmal durch mouseDragged und ein anderes mal durch den EDT. Ein revalidate in diesen Methoden führt dann auch dazu, dass dadurch noch sehr viele Folge-Events aufkommen können, die das Ganze recht langsam machen.
Evtl. solltest du den Code einiger Methoden wie folgt ersetzen:
```@Override
public void mouseDragged(MouseEvent me){
if(me.getComponent()==draggedComp){
draggedComp.setLocation(me.getX()-draggedComp.breite/2,me.getY()-draggedComp.höhe/2));
}
}
@Override
public void mousePressed(MouseEvent me){
Rectangle cursor = new Rectangle(arg0.getX(), arg0.getY(), 1, 1);
if(cursor.intersects(comp.getRect())){//comp ist Instanz der Klasse Comp ist dem Panel schon hinzugefügt
draggedComp = comp;
draggedComp.invalidate();
}
}
@Override
public void mouseReleased(MouseEvent me){
if(draggedComp!=null) {
draggedComp.validate();
gdraggedComp=null;
}
}```
Hm, schoen dass es dir helfen konnte, aber das klingt ja wieder nach einer
recht unschoenen angelegenheit. Ein thread ist ja dazu da, dass er parallel zum uebrugen
ZEug laeuft… bist du sicher dass da alles sauber ist?
UNd wie genau haeltst du den thread an? (Auch so eine sache…)
Das hat aber nichts mit “anhalten” zu tun. Du könntest ganz einfach eine [japi]Semaphore[/japi] statt der los-Variablen verwenden. Das sähe dann so aus:
while (f.isVisible()) {
semaphore.acquire();
try {
//...zeug
} finally {
semaphore.release();
}
}
}```
Und dort wo du die los-Variable auf false setzt, kommt ein semaphore.acquire() hin und dort wo die los-Variable wieder auf true gesetzt wird, kommt ein semaphore.release() hin. Die Semaphore (mit nur einem "permit") musst du bei der Erzeugung des Threads natürlich übergeben.
Das hat den Vorteil, dass du den Thread wirklich anhältst und nicht die ganze Rechenleistung eines CPU-Kernes in einer leeren Schleife verbrätst.
Man sollte von einem Thread aus sowieso nicht in die Geschehnisse auf dem Swing EDT eingreifen. Ohne Code zu sehen kann man natürlich nix dazu sagen aber ich würd mal sagen, es riecht nach stinkendem Code.
Hach die Sache ist gar nicht so schnell beschrieben. Also der EDT ist der Thread, der die ganze Arbeit in Swing macht. Wenn z.B ein Event gefeuert wird macht das der EDT. Ebenso ruft der EDT dann den MouseListener auf - alle Listener laufen auf dem EDT. Auch die paintComponent Methode der Komponenten wird vom EDT aus aufgerufen. Innerhalb des EDTs sind Manipulationen an Swing Objekten wie setLocation() problemlos. Probleme kann es aber geben wenn man von ausserhalb des EDTs auf Swing Objekte zugreift - bedingt durch die Nebenläufigkeit von Threads. Z.B könnte der EDT gerade die Position eines Komponentens neu berechnen wollen und mittendrin löscht ein anderer Thread die Komponente. Will der EDT die neue Position dann zuweisen gibts einen Error. Es können aber auch viel seltsamere und schwerer zu erkennende Dinge passieren die man sich ohne weiteres nicht erklären kann.
Wenn man von einem anderen Thread aus auf Swing Komponenten zugreifen will, sollte man das in eine Funktion packen und diese an den EDT schicken. Der hat eine sog. EventQueue, da reiht sich dein Code dann ein und wird ausgeführt sobald der EDT Zeit dazu hat. Sowas hast du doch bestimmt schon mal gesehen:
{
@Override
public void run()
{
new MyGUI();
}
}
Nach dem ganzen Text ist mir aber noch eine andere Fehlerquelle für dieses Ruckeln eingefallen. Wenn man eine Animation per Thread “falsch” macht, verschwendet man immens ressourcen und dann kanns schonmal ruckeln. Bevor ich mich dazu auslasse möchte ich aber erstmal wissen ob das überhaupt eine Animation ist. Jedenfalls sieht die Endlosschleife im Thread ohne jegliche Zeitverzögerung problematisch aus.
Ah, so meinst du das.
Naja bei unerklärlichen swing fehlern versucht man
(oder nur ich Ich ^^) immer zuerst… das, aber wo ist der unterschied zu SwingUtilities.invokeLater?
(Grad keine zeit zum grepcoden)