[pago]

Hallöchen. Ich hab dann auch mal wieder ein Problem.

Ich weiß nicht, warum es plötzlich nicht mehr funktioniert, aber irgendwie hat mein SimpleEdit-Code es geschafft, einen Bug zu erschaffen, ohne, dass ich auch nur eine Code-Zeile geändert habe.

Und zwar bin ich nicht mehr in der Lage, einen Pfad zu öffnen - weder per Maus noch per Code. Dafür zuständig ist ja prinzipiell erstmal die expandPath(TreePath)-Methode.
Sobald die Methode aufgerufen wird, passiert überhaupt nichts mehr. Da die Methode aber so simpel ist, dass es an ihr eigentlich nicht liegen kann (alle Operationen, die dort aufgerufen werden, funktionieren an sich einwandfrei). Folglich muss es an der setExpandedState(TreePath, boolean)-Methode liegen.

Mir ist aber völlig unklar, wo dort der Fehler stecken könnte.

Am Model liegt es auch nicht, da die isLeaf und getChildren-Methoden einwandfrei funktionieren.

Danke schonmal.

Edit: Neue Information: Die repaint-Methode scheint sehr häufig aufgerufen werden. Jedenfalls führt ein hinzufügen eines prints zum TreeCellRenderer dazu, dass sehr häufig der ausgegebene Text ausgegeben wird - nämlich ständig (Endlosschleife).

[mepeisen]

Hast du einen eigenen TreeCellRenderer implementiert? Oder irgendwelche TreeWillExpand-Listener u.ä. registriert? Gerade ebend jene Listener könnten auch für die Endlosschleife verantwortlich sein.

[pago]

Einen eigenen TreeCellRenderer, ja:

setCellRenderer(new DefaultTreeCellRenderer() {
			@Override
			public Component getTreeCellRendererComponent(
					JTree tree, Object value, boolean sel, boolean expanded, boolean leaf, int row, boolean hasFocus) {
				System.out.println("Repainting");
				super.getTreeCellRendererComponent(tree, value, sel, expanded, leaf, row, hasFocus);

				VFSEntry file = (VFSEntry) value;
				VirtualFileSystem system = file.getFileSystem();
				setText(system.getSystemDisplayName(file));
				setIcon(system.getSystemIcon(file));

				VFSListSelectionProxy owner = (VFSListSelectionProxy)tree.getClientProperty(VFSListSelectionProxy.CLIP_BOARD_OWNER);
				if(owner == null || !owner.isTransferedEntry(file)) {
					setForeground(MetalLookAndFeel.getBlack());
				} else {
					setForeground(MetalLookAndFeel.getControlDisabled());
				}

				return this;
			}
		});

Dazu sei folgendes gesagt: owner = null;
getSystemDisplayName() und getSystemIcon() liefern _nie_ null.

Der einzige Unterschied zum Standard renderer ist also diese Zeile:
setForeground(MetalLookAndFeel.getBlack());

[mepeisen]

Sollte nicht bewirken, dass du dort einen Endlosloop hast. Noch ein Tip zum Debugging: Maximiere nie den Browser oder Debugger, denn wenn du debuggst und dabei das Fenster wechselst, kannst du zwar debuggen aber bei nächsten Alt+Tab in den Browser wird dein Baum erneut neu gemalt und damit springts wieder in den Debugger. Entweder du entfernst den Brakepoint direkt nach dem ersten reinspringen oder du legst die Fenster nebeneinander.

Ist das immer der gleiche Node, der eine repaint-Anfrage erhält oder wie verhält sich das? Protokolliere dazu mal, welche Knotens das sind, was also im value übergeben wird und inwieweit sich die Parameter unterscheiden. Ich vermute da immer noch irgendeinen Einfluss, der dr irgendeinen Knoten permanent verändert. Achja. Interessant wäre auch, woher der TreeCellRenderer aufgerufen wird, denn der wird nicht nur zum Neu-Malen aufgerufen, sondern u.U. n-fach, nämlich auch bei dem Versuch, die Größe des JLabels (nichts anderes ist der TreeCellRenderer prinzipiell) rauszufinden. Vielleicht fragt da irgendein "Ding" nach der Knotengröße oder der TooltipManager zickt rum

[pago]

Okay, das hat mich jetzt schonmal weiter gebracht. Es liegt also nicht am TreeCellRenderer, weil der tatsächlich ordentlich abgearbeitet wird.
Hab's vorhin nochmal ausprobiert und da hat er sich nur so oft wie nötig neugezeichnet und jeden Knoten nur einmal.

[pago]

Ich füttere euch mal mit weiteren Informationen...

1) Meine Dateidialoge, die eine JList zur Darstellung benutzen, sind ebenfalls betroffen. Jeweils immer dann, wenn das Verzeichnis gewechselt wird.

2) Der Debugger bleibt beim debuggen (muahaha...) in folgender Zeile im VariableHeightLayoutCache stecken (Zeile 1478

newNode.updatePreferredSize(offset);

Und zwar beim 22 Durchlauf, wenn ich "/" öffne. Das TreeModel gibt für dieses Verzeichnis aber eine Menge von 25 Einträgen an.
Durch erweitern der getChildren(Object, int)-Methode des TreeModels fand ich raus, dass auch nur bis zum 22 Eintrag abgefragt wird. In meinem Fall heißt die entsprechende Datei "/initrd.img".

Nu könnt man ja denken: "Mensch Patrick, ist doch alles klar. Du Trottel hast das TreeModel falsch implementiert."
Jupp. Ich würd euch da gern Recht geben, nur das Model allein funktioniert einwandfrei:

public void expandPath(TreePath path) {
	int count = getModel().getChildCount(path.getLastPathComponent());
	for(int i = 0; i < count; i++) {
		System.out.println("Entry ("+i+":( "+getModel().getChild(path.getLastPathComponent(), i));
	}
	super.expandPath(path);
	// never reached
	System.out.println("Exit expand path");
}

Es kommt genau bis zum super.expandPath(path) - dadrin hörts dann halt auf.

Klingelts bei irgendwem vielleicht? Weil bei mir ist totale Ahnungslosigkeit angesagt.

3) Den ganzen Code und die letzten Änderungen sind natürlich per SVN einsehbar. http://www.javaforge.com/proj/source...g%2Fsimpleedit
Wichtig dürften org.simpleedit.vfs und org.simpleedit.vfsbrowser sein... aber keine der letzten Änderungen dürfte das Problem hervorrufen... - wie gesagt: Ohne JTree/JList funktioniert das VFS einwandfrei und die Models wurden nicht geändert...

[mepeisen]

Muss nix heissen. Wenn die anderen 3 ausserhalb des ScrollBarViews liegen..... Ich schaus mir mal bei Gelegenheit an.

[pago]

Das Fenster ist groß genug, um die alle anzuzeigen, denke ich. Aber ich probier's mal mit ner anderen Fenstergröße aus.

[pago]

Damit's auch jeder mitbekommt...:

Das Thema dürfte gegessen sein. Ich hab den TreeCellRenderer-Code auskommentiert und siehe da: Es funktioniert wieder.
Die letzte Änderung in dem Bereich war es, dass laden des Icons statt per Dateiendung via Mime-Type zu erledigen. Voila. Spur aufgenommen, fix sollte in ein paar Minuten erledigt sein.

Edit: Oh mein Gott bin ich blöd! Der Fix, falls es jemanden interessiert... ist mir schon fast zu peinlich, um das zu posten...

Aus:

while((idx = fileName.lastIndexOf('.', idx)) != -1) {

Wurde:

while((idx = fileName.lastIndexOf('.', idx-1)) != -1) {

Und das Problem war gegessen. Jetzt frag ich mir nur, warum ich das nicht eher gesehen habe. So ein Mist... *grml*