Moin,
folgendes ist zu 99% gegeben:
In einer Swing-Oberfläche ist jedem JTextField ein und der selbe FocusListener zugewiesen, der dafür sorgt, dass beim Fokus erlangen der gesamte Textinhalt des JTextFields bereits markiert wird (erleichtert das Editieren).
Zusätzlich ist für einige dieser JTextFields ein MouseListener hinterlegt, der bei Doppelklick einen Unterdialog öffnet.
Folgendes passiert aber - reproduzierbar auf 2-3 Rechnern:
Beim Doppelklick öffnet sich der Dialog nicht, stattdessen wird nur ein Teil des Inhalts des JTextFields markiert. (Bei mir selbst tritt dieses Verhalten nicht auf.)
Die Umsetzung im Quellcode ist recht simpel:
Der Fokuslistener:
{
if (e.getSource() instanceof JTextField) {
((JTextField)e.getSource()).selectAll();
}
}```
Und der Doppelklick:
Welche Erklärung gibt es dafür, dass - manchmal! - nicht der Dialog geöffnet und stattdessen nur ein Teil des Textfeldinhalts markiert wird?
Und wie kann man das abstellen? Wo ist der Denkfehler?
Moin,
nein, habe ich nicht - das ist ja immer lästig, weil ich es selbst bei mir nicht reproduzieren kann und bei neuen Versuchen immer die Anwender belästigen muss. Deren Geduld ist endlich, und wenn ich ein halbes Dutzend mal bei ihnen auftauche, ohne dass sich was ändert, halten sie mich irgendwann für unfähig.
Ich glaube auch nicht, dass es daran liegt. Zuerst wird übrigens der MouseListener gesetzt, danach erst der FocusListener. Ich hätte eher vermutet, dass bei umgekehrter Reihenfolge möglicherweise dieses Problem auftritt. Oder welche Idee hast Du?
Warum der Dialog nicht erscheint, weiß ich momentan auch nicht, aber … Das mit dem Markieren könnte mit dem Standardverhalten eines JTextFields zusammenhängen:
Einfach-Klick: Positioniert den Cursor
Doppel-Klick: Markiert das angeklickte Wort (!)
Dreifach-Klick (!): Markiert den gesamten Text
Dazu kommt noch, dass das JTextField (mindestens) einen MouseMotionListener hat, der beim Draggen den überdraggten Text markiert. Bei grobmotorigen Anwendern kann das auch das vorher getätigte “selectAll” wieder zunichte machen…
Abhilfen für diese Probleme wüßte ich spontan auch nicht - die MouseListener (die wohl vom javax.swing.plaf.basic.BasicTextUI hinzugefügt werden) “von Hand” zu entfernen wäre ziemlich murksig… aber vielleicht hilft die Info ja als grober Ansatz…
Moin,
danke für die Infos. Wodurch ich aber noch immer nicht verstehe,
weshalb beim Doppelklick nicht über den MouseListener der Dialog geöffnet wird.
weshalb manchmal beim Doppelklick auch nur ein Teil des Inhalts markiert wird, z.B. nur ‚71‘ von ‚713‘. Ich habe es selbst am Arbeitsplatz des Anwenders ausprobiert und konnte es reproduzieren, an meinem Arbeitsplatz nicht…
Ich glaube ich gehe wirklich mal mit meiner Computermaus zu ihm hin und lasse ihn das noch mal ausprobieren. Aber wenn das damit behoben ist, wo bekomme ich dann eine neue Maus her?
Dessen bin ich jetzt nicht sicher. Aber kann das erklären, weshalb das Verhalten auf einem bis drei Rechnern auftritt, auf anderen aber wiederum nicht? Will mir nicht so ganz einleuchten. Müsste das dann nicht auf allen Rechnern auftreten?
Ich muss mich diesbezüglich wohl mal ein bisschen einlesen, weil ich nicht weiß, was du damit genau meinst, ob alles an Swing im EDT läuft. Wenn damit gemeint ist, dass die Oberfläche so gestartet wird in der main-Methode
public void run() {
new EingabeForm().setVisible(true);
}
});```
dann kann ich das verneinen.
Es geht nicht nur um den Start der Oberfläche, sondern eigentlich sollte generell ALLES, was mit Swing zu tun hat, im EDT laufen. Wenn von hier aus aber alles gesteuert wird, dann dürfte wohl dank diesem Schnippsel alles im EDT laufen.
EDT = Event-Dispatch Thread. Da Swing nicht Threadsafe ist sollten auch alle Operationen, die die Swing-GUI betreffen im selben Thread ablaufen, in welchem auch Swing läuft => im EDT .
Hm… das Problem müsste eigentlich reproduzierbar sein. Wenn es das nicht ist, dann muss es irgend einen Unterschied zwischen den Testrechnern geben. Was mir da so spontan einfällt:
Betriebssystem
Maustreiber
oder vielleicht doch irgendwelche Unterschiede im Code (und wenn es irgendwelche alten Libaries sind oder sowas, in dem Bereich lieber alles nochmal überprüfen)
Aber eigentlich fällt mirs schwer auch das mit dem Maustreiber oder so in Betracht zu ziehen. Notfalls muss man sich die Sourcen von Java besorgen und das Problem und die funktionierende Version debuggen. Wäre natürlich nen schweine Aufwand, aber wenn du das Problem bei dir nicht reproduzieren kannst dann ist es halt auch ziemlich unwahrscheinlich, dass du es lösen kannst.
Wenn du ein kleines kompilierbares Beispiel zur Verfügung stellen könntest würde ich mal testen wies bei mir aussieht. Vielleicht kann ja einer von uns den Fehler reproduzieren und dem Problem auf die Schliche kommen.
Ungünstige Konstellation von noch unglücklicheren Gegebenheiten auf manchen Rechnern. Fehler in Threads bzw. Fehler die durch Threads verursacht wurden sind manchmal sehr schwer nachzuvollziehen .
Schon klar. Leider handelt es sich dabei um ein eingekauftes Programm, welches dazu sehr umfangreich und komplex ist. Mit anderen Worten: Weder habe ich die Lust dazu, mich wegen so einem Killefit tage- oder gar wochenlang damit zu beschäftigen, noch wird mir der Kunde dafür grünes Licht (=Geld) geben.
Schätze, die 2-3-4 Anwender, die das Verhalten bisher meldeten, werden zunächst mit dieser leichten Unpässlichkeit leben müssen.
Danke trotzdem schon mal für die Hinweise, vielleicht hilft mir das irgendwann einmal weiter.
Ich habe den Thread erst jetzt gelesen.
Daß das Programm nicht auf dem EventDispatchThread ist, halte ich für eher unwahrscheinlich,
denn dann müsst ja jedesmal ein Backgroundthread gestartet werden.
Wir können das feststellen mit “SwingUtilities.isEventDispatchThread()”.
Könnte es sein, daß die Einstellung der Maus so ist, daß sie schon geringste, ungewollte
Draggingbewegungen erkennt? Das könnte das Verhalten vielleicht erklären.
.