JFileChooser und das erste Mal

[Stefan1200]

...nein, nicht das was Ihr denkt

Ist es normal, wenn ein JFileChooser das erste Mal nach dem Programmstart aufgerufen wird, das es sehr lange dauert, bis das Fenster zu sehen ist? Gibt es da ein Trick für, oder bleibt einem nur warten, bzw. das nutzen von FileDialog?

Ohne vorher ein Hinweistext auszugeben, das es mitunter 30-40 Sekunden dauern kann, denken doch viele Leute das Java Programm sei gecrashed

 

[mariopetr]

hallo,

ja, ist normal. zum einen muss die klasse erst geladen werden, zum anderen sucht er ganz schoen auf dem filesystem rum. als alternative kannst du ja beim start deines programms einen filechooser in einem thread instanziieren, aber nicht anzeigen

 

[marsias]

Hi!

Also das das laden soooo lange dauert? das kann natürlich an deinen rechner liegen..
bei mir geht es ruck zuck... 1,4 Ghz...aber stimmt das er rumsucht...
versuch ihm mal ein startverzeichniss zu übergeben vielleicht geht es besser?

mfg

 

[jptc.org]

Generell braucht der JFileChooser immer beim Startup extrem länger als bei den folgenden Aufrufen. Die Ladegeschwindigkeit hängt von vielen Faktoren ab (Hardware - nicht nur Prozessor, Betriebssystem usw.). Die Verwendung eines initialen Pfades bringt keine Performancepluspunkte. Am besten ist, wenn man den JFileChooser beim Startup läd. Schau doch mal den Post beim Java Performance Portal an:

http://www.jptc.org/modules.php?name=Forums&file=viewtopic&t=10

Für weitere Fragen stehe ich gerne zur Verfügung.

Karsten Voigt

http://www.java-performance-portal.org

 

[Nobody]

grad ist mir ne idee gekommen: starte in einem extra thread eine msg box die den user auf das laden hinweist.

 

[jptc.org]

grad ist mir ne idee gekommen: starte in einem extra thread eine msg box die den user auf das laden hinweist.

Das ganze könnte sogar funktionieren, wenn es da nicht ein Problem gebe: Swing ist nicht thread safe. Auf alle Komponente sollte nur vom (Main) Eventdispatcher Thread zugegriffen werden. Es sollten niemals neue Dialoge oder ähnliches in einem separtem Thread gestartet werden. Eine ähnliche Problematik wird im Post

http://www.java-forum.net/viewtopic.php?t=166

dargestellt. Ausserdem werden viele Nutzer an einer Anwendung zweifeln, die darauf hinweist dass die Anzeige eines Filedialoges etwas länger dauern kann (zumindest denke ich das). :roll:

Karsten Voigt
http://www.java-performance-portal.org

 

[DTR]

Da es sich ja hier nur um eine kleine Meldung handelt dürfte es nicht all zuviel ausmachen, das Swing nicht threadsave ist. Man kann durchaus Swingelemente in verschiedenen Threads verwenden, wenn man weiß was man macht.

Ich denke es ist schon sinnvoll eine Nachricht zu bringen, daß das Programm am laden des FileChoosers ist. Denn ein Programm, das sich anscheinend aufgehängt hat ist meiner ansicht nach noch abschrekender. Es hängt allso immer davon ab, wie lange die zu erwartende Pause ist.

 

[Stefan1200]

Bisher habe ich das immer so gemacht, das ich in der Titelzeile ein hinweistext bringe, das man warten möchte.

Bzw. bei manchen Programmen habe ich halt den AWT FileDialog eingebaut. Der kommt sofort.

 

[jptc.org]

Schon um einen sauber Code zu erhalten sollte man AWT und Swing nicht mischen. Auf die restlichen Nachteile möchte ich hier nicht eingehen. Das mit dem Hinweistext in der Titelzeile kann durchaus gemacht werden, besonders wenn man bedenkt, dass das Problem nur beim ersten Aufruf auftritt.

Karsten Voigt
http://www.java-performance-portal.org

 

[Stefan1200]

Schon um einen sauber Code zu erhalten sollte man AWT und Swing nicht mischen. Auf die restlichen Nachteile möchte ich hier nicht eingehen. Das mit dem Hinweistext in der Titelzeile kann durchaus gemacht werden, besonders wenn man bedenkt, dass das Problem nur beim ersten Aufruf auftritt.

Naja, was heisst mischen. Ich habe eine extra Klasse geschrieben, in dem ich dann Titeltext und FileDialog Typ (LOAD, SAVE) übergebe, und den Pfad zurück bekomme. In dieser Klasse habe ich dann auch nur AWT, und in der Programmklasse nur reines Swing.

Also gemischt habe ich das nicht, das ist komplett voneinander getrennt.
Das geht doch noch in Ordnung, oder nicht?

 

[jptc.org]

Also normalweise sollte eine GUI nur aus Swing oder nur aus AWT bestehen, ist dies nicht zu vermeiden, so sollte man ein paar kleine Regeln beachten (ich bin jetzt zu faul das zu übersetzen :lol: )

1. Do not mix lightweight (Swing) and heavyweight (AWT) components in a container if the lightweight component must be displayed on top of the heavyweight (AWT legt sich immer über Swing, egal was man macht)
2. If a popup menu intersects a heavyweight component, force the popup menu to be heavyweight.
3. Don't add heavyweight components to an instance of JScrollPane (denn es wird nicht funktionieren)
4. Don't add heavyweight components to Swing internal frames.

Im Falle des FileChooser funktioniert das schon, jedoch ist es kein guter Stil und was ist wenn man sich überlegt AWT einzufrieren und gar nicht mehr mit auszuliefern? Prinzipiell sollte man die Vermischung von AWT mit Swing nur im Ausnahmefall als Übergangslösung verwenden.

Karsten Voigt
http://www.java-performance-portal.org