Thread in Swing? Alternativen?
peter
Ich schreibe einen XML-Editor, der die Tatsache, dass XML verwendet
wird, vor dem Benutzer versteckt. Die Elemente werden nur über
Element-Zeichen dargestellt.
Das Problem:
Wenn der Benutzer nur ein Tag entfernt, muss sicher gestellt werden,
dass das zugehörige öffnende oder schließende Tag auch gelöscht
wird. Ich teste nun im DocumentListener, ob es sich bei dem gelöschten
Zeichen um ein Element-Zeichen handelt. Wenn ja, versuche ich, das
zugeörige Element-Zeichen zu löschen.
Nur leider kommt dann die Fehlermeldung:
Exception in thread "AWT-EventQueue-1" java.lang.IllegalStateException:
Attempt to mutate in notification
at javax.swing.text.AbstractDocument.writeLock(Unknown Source)
at javax.swing.text.AbstractDocument.remove(Unknown Source)
at
myApplet.MyDocumentListener.updateElemPositionsAfterRemove(MyDocumentListener.java:156)
Es sieht wohl so aus, dass wenn ich mich innerhalb des
DocumentListeners befinde, das Document vor weiteren Veränderungen
schreibgeschützt wird.
Theoretisch könnte ich wohl die Klasse AbstractDocument ableiten und
den Schreibschutz entfernen, was mir allerdings etwas riskant zu sein
scheint! (oder?)
Nur wie kann ich das Problem sonst lösen?
Habe an einen Thread gedacht, der alle paar Milisekunden nachschaut, ob
das globale Flag auf
"es_wurde_gerade_ein_einzelnes_Element-Zeichen_gelöscht" == true
gesetzt ist. Nur habe ich überhaupt keine Erfahrung mit Threads und
habe gelesen, dass Swing nicht thread-sicher sei. Heißt das, ich kann
Threads mit Swing nicht verwenden?
Vielleicht gibt es ja auch noch eine andere Lösung, auf die ich noch
gar nicht gekommen bin? Ich weiß nicht mehr weiter!
Vielen Dank für Eure Hilfe,
Peter
Michael Hüttermann
peter schrieb:
schlechte idee mit dem flag.
swing ist nicht thread-sicher, allerdings kannst du deine komponenten
bzw. den zugriff darauf thread-sicher machen. ähnlich wie es sun mit
dem document gemacht hat welches du mal eben hinterrücks ändern
möchtest. lies dich am besten mal etwas ein was es bedeutet mit
threads zu arbeiten und locks auf objekten zu haben. kannst du nicht
diese xml-konvertierung nur einmal machen, zB wenn der user das feld
verlässt? dann ersparst du dir einiges an ärger.
>
> Vielleicht gibt es ja auch noch eine andere Lösung, auf die ich noch
> gar nicht gekommen bin? Ich weiß nicht mehr weiter!
Michae
peter
> schlechte idee mit dem flag.
>
> swing ist nicht thread-sicher, allerdings kannst du deine komponenten
> bzw. den zugriff darauf thread-sicher machen. ähnlich wie es sun mit
> dem document gemacht hat welches du mal eben hinterrücks ändern
> möchtest. lies dich am besten mal etwas ein was es bedeutet mit
> threads zu arbeiten und locks auf objekten zu haben. kannst du nicht
> diese xml-konvertierung nur einmal machen, zB wenn der user das feld
> verlässt? dann ersparst du dir einiges an ärger.
Leider macht das keinen Sinn.
Vielleicht nur kurz zur Verdeutlichung, was mir vorschwebt:
Ich habe keine einzelnen Felder, sondern i.W. nur ein JTextPane mit
darunter liegendem StyledDocument, in das der XML-Text reingeschrieben
wird. Dabei soll der Benutzer z.B. einzelne Woerter markieren und ihnen
dann ein bestimmtes XML-Element zuweisen koennen, das dann mit
oeffnenden und schliessenden Element-Zeichen im Text angezeigt wird ...
Wenn Threads also in Swing nichts taugen, muss ich mich wirklich ans
Abwandeln von AbstractDocument heranwagen oder gibt es noch andere
Alternativen?
Gruss,
Peter
Wanja Gayk
> Das Problem:
> Wenn der Benutzer nur ein Tag entfernt, muss sicher gestellt werden,
> dass das zugehörige öffnende oder schließende Tag auch gelöscht
> wird. Ich teste nun im DocumentListener, ob es sich bei dem gelöschten
> Zeichen um ein Element-Zeichen handelt. Wenn ja, versuche ich, das
> zugeörige Element-Zeichen zu löschen.
> Nur leider kommt dann die Fehlermeldung:
>
> Exception in thread "AWT-EventQueue-1" java.lang.IllegalStateException:
> Attempt to mutate in notification
> at javax.swing.text.AbstractDocument.writeLock(Unknown Source)
> at javax.swing.text.AbstractDocument.remove(Unknown Source)
> at
> myApplet.MyDocumentListener.updateElemPositionsAfterRemove(MyDocumentListener.java:156)
>
> Es sieht wohl so aus, dass wenn ich mich innerhalb des
> DocumentListeners befinde, das Document vor weiteren Veränderungen
> schreibgeschützt wird.
Richtig.
Du könntest die Veränderungen aber mit einem:
SwingUtilities.invokeLater(Runnable)
ausführen, nachdem der Listener abgearbeitet ist.
Oder du baust dir eine Queue, die von einem Thread abgearbeitet wird und
pollst deine Ändetrungen in diese Queue (analog zu invokeLater nur ohne
im EDT zu sein), siehe dazu z.B.:
> http://groups.google.com/group/de.comp.lang.java/msg/1840eef47b8cf463?&hl=en
Gruß,
-Wanja-
--
"Gewisse Schriftsteller sagen von ihren Werken immer: 'Mein Buch, mein
Kommentar, meine Geschichte'. [..] Es wäre besser, wenn sie sagten:
'unser Buch, unser Kommentar, unsere Geschichte'; wenn man bedenkt, dass
das Gute darin mehr von anderen ist als von ihnen." [Blaise Pascal]
Michael Hüttermann
peter schrieb:
niemand hat behauptet dass threads in swing nichts taugen!?! wenn du es
in echtzeit benötigst dann mach es halt in echtzeit. dann musst du das
nebenläufig machen unter berücksichtigung bestehender locks.
Michael
peter
vielen Dank! Scheint zu funktionieren!
Hier mein Code ...
setDelPos(elem_to_update.getTextStop_Pos());
Runnable deleteOtherTag = new Runnable() {
public void run() {
try{
styledDoc.remove(getDelPos(),1);
}
catch(BadLocationException e){
e.printStackTrace();
}
}
};
SwingUtilities.invokeLater(deleteOtherTag);
Gruß,
Peter
Wanja Gayk
Paul Ebermann
> Ich schreibe einen XML-Editor, der die Tatsache, dass XML verwendet
> wird, vor dem Benutzer versteckt. Die Elemente werden nur über
> Element-Zeichen dargestellt.
Was für "Element-Zeichen"?
> Das Problem:
> Wenn der Benutzer nur ein Tag entfernt, muss sicher gestellt werden,
> dass das zugehörige öffnende oder schließende Tag auch gelöscht
> wird. Ich teste nun im DocumentListener, ob es sich bei dem gelöschten
> Zeichen um ein Element-Zeichen handelt. Wenn ja, versuche ich, das
> zugeörige Element-Zeichen zu löschen.
Anstatt einen DocumentListener zu bemühen (und von da aus etwas
am Document zu ändern), würde ich lieber direkt ein eigenes
Document implemtieren - als Datenbasis kann das ja ein DOM
o.ä. haben.
Paul
--
Wem es darum zu tun ist, dauerhafte Achtung sich zu erwerben; [...] der würze
nicht ohne Unterlass seine Gespräche mit Lästerungen, Spott und Medisance und
gewöhne sich nicht an den auszischenden Ton von Persiflage.
Adolf Freiherr Knigge, Über den Umgang mit Menschen, 1.17