JTree (Tutorial)© - Versionsgeschichte

L-ectron-X am 8. April 2018 um 11:37 Uhr

2018-04-08T11:37:41Z

← Nächstältere Version		Version vom 8. April 2018, 11:37 Uhr
Zeile 1.474:		Zeile 1.474:
	{{Fragen stellen}}		{{Fragen stellen}}

	~~[[Kategorie:Java]]~~
	[[Kategorie:Swing]]		[[Kategorie:Swing]]
	[[Kategorie:Tutorials (Java)]]		[[Kategorie:Tutorials (Java)]]

	--[[Benutzer:Beni \| Beni]] (© Benjamin Sigg 03.12.2005, 14:25)		--[[Benutzer:Beni \| Beni]] (© Benjamin Sigg 03.12.2005, 14:25)

L-ectron-X am 8. März 2018 um 19:08 Uhr

2018-03-08T19:08:24Z

Änderungen zeigen

L-ectron-x: /* Eigene TreeModels */

2017-11-21T15:25:08Z

Eigene TreeModels

← Nächstältere Version		Version vom 21. November 2017, 15:25 Uhr
Zeile 834:		Zeile 834:
	Wie oben bereits erwähnt arbeitet das {{JAPI\|DefaultTreeModel}} intern mit {{JAPI\|DefaultMutableTreeNode}}s. Wenn man eine eigene, bestehende Datenstruktur hat, die bereits hierarchisch aufgebaut ist, ist es nicht mehr notwendig, die Daten noch einmal in DefaultMutableTreeNodes zu verpacken, um sie dann dem JTree zuzuführen. In diesem Fall schreibt man ein eigenes TreeModel.		Wie oben bereits erwähnt arbeitet das {{JAPI\|DefaultTreeModel}} intern mit {{JAPI\|DefaultMutableTreeNode}}s. Wenn man eine eigene, bestehende Datenstruktur hat, die bereits hierarchisch aufgebaut ist, ist es nicht mehr notwendig, die Daten noch einmal in DefaultMutableTreeNodes zu verpacken, um sie dann dem JTree zuzuführen. In diesem Fall schreibt man ein eigenes TreeModel.

	Wenn man ein eigenes TreeModel verwendet, hat man ein bisschen mehr Arbeit. Sobald ein TreeModel irgendwo benutzt wird, werden ihm ~~TreeModelListeners~~ hinzugefügt (über die Methode addTreeModelListener()). Hinter diesen Listenern können sich JTrees verbergen, selbstgeschriebene Programmteile, oder irgendwelche TreeUI's des aktuellen LookAndFeels...		Wenn man ein eigenes TreeModel verwendet, hat man ein bisschen mehr Arbeit. Sobald ein TreeModel irgendwo benutzt wird, werden ihm {{JAPI\|TreeModelListener}}s hinzugefügt (über die Methode <code>addTreeModelListener()</code>). Hinter diesen Listenern können sich JTrees verbergen, selbstgeschriebene Programmteile, oder irgendwelche TreeUI's des aktuellen [[LookAndFeel\|LookAndFeels]]...
	Jedenfalls: wenn man einen veränderlichen Baum hat, müssen diese Listener gespeichert werden.		Jedenfalls: wenn man einen veränderlichen Baum hat, müssen diese Listener gespeichert werden.
	Sobald sich der Baum irgendwie verändert hat, müssen alle [[Listener]] mit einem korrekt aufgebauten {{JAPI\|TreeModelEvent}} aufgerufen werden.		Sobald sich der Baum irgendwie verändert hat, müssen alle [[Listener]] mit einem korrekt aufgebauten {{JAPI\|TreeModelEvent}} aufgerufen werden.

L-ectron-x: /* Eigene TreeModels */

2017-11-21T15:22:36Z

Eigene TreeModels

← Nächstältere Version		Version vom 21. November 2017, 15:22 Uhr
Zeile 832:		Zeile 832:

	==Eigene TreeModels==		==Eigene TreeModels==
	Wie oben bereits erwähnt arbeitet das {{JAPI\|DefaultTreeModel}} intern mit {{JAPI\|DefaultMutableTreeNode}}s. Wenn man eine eigene, bestehende Datenstruktur hat, die bereits hierarchisch aufgebaut ~~sind~~, ist es ~~oft~~ nicht mehr notwendig, die Daten noch einmal in DefaultMutableTreeNodes zu verpacken, um sie dann dem JTree zuzuführen. In diesem Fall schreibt man ein eigenes TreeModel.		Wie oben bereits erwähnt arbeitet das {{JAPI\|DefaultTreeModel}} intern mit {{JAPI\|DefaultMutableTreeNode}}s. Wenn man eine eigene, bestehende Datenstruktur hat, die bereits hierarchisch aufgebaut ist, ist es nicht mehr notwendig, die Daten noch einmal in DefaultMutableTreeNodes zu verpacken, um sie dann dem JTree zuzuführen. In diesem Fall schreibt man ein eigenes TreeModel.

	Wenn man ein eigenes TreeModel verwendet, hat man ein bisschen mehr Arbeit. Sobald ein TreeModel irgendwo benutzt wird, werden ihm TreeModelListeners hinzugefügt (über die Methode addTreeModelListener()). Hinter diesen Listenern können sich JTrees verbergen, selbstgeschriebene Programmteile, oder irgendwelche TreeUI's des aktuellen LookAndFeels...		Wenn man ein eigenes TreeModel verwendet, hat man ein bisschen mehr Arbeit. Sobald ein TreeModel irgendwo benutzt wird, werden ihm TreeModelListeners hinzugefügt (über die Methode addTreeModelListener()). Hinter diesen Listenern können sich JTrees verbergen, selbstgeschriebene Programmteile, oder irgendwelche TreeUI's des aktuellen LookAndFeels...

L-ectron-x: /* Eigene TreeModels */

2017-11-21T15:15:46Z

Eigene TreeModels

← Nächstältere Version		Version vom 21. November 2017, 15:15 Uhr
Zeile 832:		Zeile 832:

	==Eigene TreeModels==		==Eigene TreeModels==
	Wie oben bereits erwähnt arbeitet das {{JAPI\|DefaultTreeModel}} intern mit {{JAPI\|DefaultMutableTreeNode}}s. Wenn man eine eigene, bestehende ~~Daten~~ hat, die bereits hierarchisch aufgebaut sind, ist es oft nicht mehr notwendig, die Daten noch einmal in DefaultMutableTreeNodes zu verpacken, um sie dann dem JTree zuzuführen. In diesem Fall schreibt man ein eigenes TreeModel.		Wie oben bereits erwähnt arbeitet das {{JAPI\|DefaultTreeModel}} intern mit {{JAPI\|DefaultMutableTreeNode}}s. Wenn man eine eigene, bestehende Datenstruktur hat, die bereits hierarchisch aufgebaut sind, ist es oft nicht mehr notwendig, die Daten noch einmal in DefaultMutableTreeNodes zu verpacken, um sie dann dem JTree zuzuführen. In diesem Fall schreibt man ein eigenes TreeModel.

	Wenn man ein eigenes TreeModel verwendet, hat man ein bisschen mehr Arbeit. Sobald ein TreeModel irgendwo benutzt wird, werden ihm TreeModelListeners hinzugefügt (über die Methode addTreeModelListener()). Hinter diesen Listenern können sich JTrees verbergen, selbstgeschriebene Programmteile, oder irgendwelche TreeUI's des aktuellen LookAndFeels...		Wenn man ein eigenes TreeModel verwendet, hat man ein bisschen mehr Arbeit. Sobald ein TreeModel irgendwo benutzt wird, werden ihm TreeModelListeners hinzugefügt (über die Methode addTreeModelListener()). Hinter diesen Listenern können sich JTrees verbergen, selbstgeschriebene Programmteile, oder irgendwelche TreeUI's des aktuellen LookAndFeels...

L-ectron-x: /* Eigene TreeModels */

2017-11-21T14:52:24Z

Eigene TreeModels

← Nächstältere Version		Version vom 21. November 2017, 14:52 Uhr
Zeile 832:		Zeile 832:

	==Eigene TreeModels==		==Eigene TreeModels==
			Wie oben bereits erwähnt arbeitet das {{JAPI\|DefaultTreeModel}} intern mit {{JAPI\|DefaultMutableTreeNode}}s. Wenn man eine eigene, bestehende Daten hat, die bereits hierarchisch aufgebaut sind, ist es oft nicht mehr notwendig, die Daten noch einmal in DefaultMutableTreeNodes zu verpacken, um sie dann dem JTree zuzuführen. In diesem Fall schreibt man ein eigenes TreeModel.

	Wenn man ein eigenes TreeModel verwendet, hat man ein bisschen mehr Arbeit. Sobald ein TreeModel irgendwo benutzt wird, werden ihm TreeModelListeners hinzugefügt (über die Methode addTreeModelListener()). Hinter diesen Listenern können sich JTrees verbergen, selbstgeschriebene Programmteile, oder irgendwelche TreeUI's des aktuellen LookAndFeels...		Wenn man ein eigenes TreeModel verwendet, hat man ein bisschen mehr Arbeit. Sobald ein TreeModel irgendwo benutzt wird, werden ihm TreeModelListeners hinzugefügt (über die Methode addTreeModelListener()). Hinter diesen Listenern können sich JTrees verbergen, selbstgeschriebene Programmteile, oder irgendwelche TreeUI's des aktuellen LookAndFeels...
	Jedenfalls: wenn man einen veränderlichen Baum hat, müssen diese Listener gespeichert werden.		Jedenfalls: wenn man einen veränderlichen Baum hat, müssen diese Listener gespeichert werden.

L-ectron-x: /* Eigene TreeModels */

2017-09-24T14:50:37Z

Eigene TreeModels

L-ectron-x: /* Das DefaultTreeModel */

2017-09-24T14:48:57Z

Das DefaultTreeModel

← Nächstältere Version		Version vom 24. September 2017, 14:48 Uhr
Zeile 826:		Zeile 826:

	==Das DefaultTreeModel==		==Das DefaultTreeModel==
	Das DefaultTreeModel ist ein TreeModel, welches mit ~~TreeNodes~~ befüllt wird. Wenn man nun einen TreeNode verändert hat, muss man das Model von diesen Veränderungen unterrichten.		Das {{JAPI\|DefaultTreeModel}} ist ein {{JAPI\|TreeModel}}, welches mit {{JAPI\|TreeNode}}s befüllt wird. Wenn man nun einen TreeNode verändert hat, muss man das Model von diesen Veränderungen unterrichten.
	Hat man z.B. den Text eines Nodes verändert, ruft man nodeChanged() auf. Der Rest erledigt sich automatisch.		Hat man z.B. den Text eines Nodes verändert, ruft man <code>nodeChanged()</code> auf. Der Rest erledigt sich automatisch.
	Um einen Knoten einzufügen, ruft man entweder direkt insertNodeInto() auf (und das Model wird den Kindknoten dem Vaterknoten einsetzen), oder man ruft nodesWereInserted() auf, nachdem der Knoten eingefügt wurde.		Um einen Knoten einzufügen, ruft man entweder direkt <code>insertNodeInto()</code> auf (und das Model wird den Kindknoten dem Vaterknoten einsetzen), oder man ruft <code>nodesWereInserted()</code> auf, nachdem der Knoten eingefügt wurde.
	Es gibt noch ~~einen ganzen~~ Bündel weiterer solcher Methoden, aber ihre Beschreibungen können in der API nachgelesen werden.		Es gibt noch ein ganzes Bündel weiterer solcher Methoden, aber ihre Beschreibungen können in der Doku der [[API]] nachgelesen werden.

	==Eigene TreeModels==		==Eigene TreeModels==

L-ectron-x: /* TreeNode */

2017-07-21T16:39:41Z

TreeNode

← Nächstältere Version		Version vom 21. Juli 2017, 16:39 Uhr
Zeile 31:		Zeile 31:

	==TreeNode==		==TreeNode==
	Die wohl intuitivste Variante Daten in einen JTree zu bringen, sind {{JAPI\|~~TreeNodes~~}}. Jeder dieser Nodes stellt einen Knoten des Baumes dar, und hat eine beliebige Anzahl Kindknoten. TreeNode selbst ist nur ein [[Interface]]. Entweder schreibt man selbst eine [[Klasse]] welche das Interface implementiert, oder man benutzt den sehr bequemen {{JAPI\|DefaultMutableTreeNode}}.		Die wohl intuitivste Variante Daten in einen JTree zu bringen, sind {{JAPI\|TreeNode}}s. Jeder dieser Nodes stellt einen Knoten des Baumes dar, und hat eine beliebige Anzahl Kindknoten. TreeNode selbst ist nur ein [[Interface]]. Entweder schreibt man selbst eine [[Klasse]] welche das Interface implementiert, oder man benutzt den sehr bequemen {{JAPI\|DefaultMutableTreeNode}}.

	Die {{JAPI\|MutableTreeNode}} sind nur [[Wrapper]] um ein Userobject herum. Das Userobject bestimmt den Wert des Knotens, die Knoten selbst bestimmen die Struktur des Baumes.		Die {{JAPI\|MutableTreeNode}} sind nur [[Wrapper]] um ein Userobject herum. Das Userobject bestimmt den Wert des Knotens, die Knoten selbst bestimmen die Struktur des Baumes.

L-ectron-x: /* Veränderliche Daten */

2017-07-16T13:05:00Z

Veränderliche Daten

← Nächstältere Version		Version vom 16. Juli 2017, 13:05 Uhr
Zeile 823:		Zeile 823:
	=Veränderliche Daten=		=Veränderliche Daten=
	Richtig interessant werden Bäume erst, wenn sie auch veränderlich sind. In diesem Kapitel geht es um Bäume, welche von programminternen Prozessen, und nicht vom Benutzer, verändert werden. Verändern kann bedeuten: einen Knoten hinzufügen, einen Knoten entfernen, oder die "Daten" eines Knotens (und damit seine Darstellung) verändern.		Richtig interessant werden Bäume erst, wenn sie auch veränderlich sind. In diesem Kapitel geht es um Bäume, welche von programminternen Prozessen, und nicht vom Benutzer, verändert werden. Verändern kann bedeuten: einen Knoten hinzufügen, einen Knoten entfernen, oder die "Daten" eines Knotens (und damit seine Darstellung) verändern.
			Ein Beispiel für einen veränderbaren JTree findet man in diesem Wiki im Artikel [https://wiki.byte-welt.net/wiki/JTree_Zustand_speichern JTree - Zustand speichern]. Dort wird auch erklärt, wie man die Struktur eines JTree speichern kann.

	==Das DefaultTreeModel==		==Das DefaultTreeModel==
Zeile 1.068:		Zeile 1.069:
	}		}
	</code=java>		</code=java>



	=Benutzerinteraktion=		=Benutzerinteraktion=

← Nächstältere Version		Version vom 24. September 2017, 14:50 Uhr
Zeile 834:		Zeile 834:
	Wenn man ein eigenes TreeModel verwendet, hat man ein bisschen mehr Arbeit. Sobald ein TreeModel irgendwo benutzt wird, werden ihm TreeModelListeners hinzugefügt (über die Methode addTreeModelListener()). Hinter diesen Listenern können sich JTrees verbergen, selbstgeschriebene Programmteile, oder irgendwelche TreeUI's des aktuellen LookAndFeels...		Wenn man ein eigenes TreeModel verwendet, hat man ein bisschen mehr Arbeit. Sobald ein TreeModel irgendwo benutzt wird, werden ihm TreeModelListeners hinzugefügt (über die Methode addTreeModelListener()). Hinter diesen Listenern können sich JTrees verbergen, selbstgeschriebene Programmteile, oder irgendwelche TreeUI's des aktuellen LookAndFeels...
	Jedenfalls: wenn man einen veränderlichen Baum hat, müssen diese Listener gespeichert werden.		Jedenfalls: wenn man einen veränderlichen Baum hat, müssen diese Listener gespeichert werden.
	Sobald sich der Baum irgendwie verändert hat, müssen alle Listener mit einem korrekt aufgebauten TreeModelEvent aufgerufen werden.		Sobald sich der Baum irgendwie verändert hat, müssen alle [[Listener]] mit einem korrekt aufgebauten {{JAPI\|TreeModelEvent}} aufgerufen werden.

	Grundsätzlich gibt es 4 unterschiedliche Kategorien von Ereignissen: Knoten wurden entfernt, Knoten wurden hinzugefügt, Knoten wurden verändert oder die Änderungen sind zu komplex um von den 3 anderen Kategorien erfasst zu werden.		Grundsätzlich gibt es 4 unterschiedliche Kategorien von Ereignissen: Knoten wurden entfernt, Knoten wurden hinzugefügt, Knoten wurden verändert oder die Änderungen sind zu komplex um von den 3 anderen Kategorien erfasst zu werden.
	Der Listener bietet folgende 4 Methoden, passend zu diesen Kategorien:		Der Listener bietet folgende 4 Methoden, passend zu diesen Kategorien:
	*treeNodesChanged()		*<code>treeNodesChanged()</code>
	Wenn einer oder mehrere Knoten ihre Daten, nicht aber den Platz im Baum verändert haben. "Ihre Daten verändert" bedeutet, dass sich ihre Darstellung verändert hat, und sie neu gezeichnet werden sollen.		Wenn einer oder mehrere Knoten ihre Daten, nicht aber den Platz im Baum verändert haben. "Ihre Daten verändert" bedeutet, dass sich ihre Darstellung verändert hat, und sie neu gezeichnet werden sollen.
	Das TreeModelEvent enthält den Pfad zu dem Vaterknoten der veränderten Knoten, ausserdem einen Array mit den Indizes, sowie ein weiterer Array mit den veränderten Knoten. Sollte sich die Wurzel verändert haben, sind diese beiden Arrays auf null zu setzen.		Das TreeModelEvent enthält den Pfad zu dem Vaterknoten der veränderten Knoten, ausserdem einen Array mit den Indizes, sowie ein weiterer Array mit den veränderten Knoten. Sollte sich die Wurzel verändert haben, sind diese beiden Arrays auf null zu setzen.
	*treeNodesInserted()		*<code>treeNodesInserted()</code>
	Diese Methode sollte aufgerufen werden, wenn Knoten in den Baum eingefügt wurden. Das Event besitzt den Pfad zu dem Vaterknoten der neuen Knoten. ~~Ausserdem~~ einen Array der neuen Knoten selbst, sowie der Indizes der neuen Knoten. Diese beiden Arrays müssen aufsteigend sortiert sein.		Diese Methode sollte aufgerufen werden, wenn Knoten in den Baum eingefügt wurden. Das Event besitzt den Pfad zu dem Vaterknoten der neuen Knoten. Außerdem einen Array der neuen Knoten selbst, sowie der Indizes der neuen Knoten. Diese beiden Arrays müssen aufsteigend sortiert sein.
	*treeNodesRemoved()		*<code>treeNodesRemoved()</code>
	Soll benutzt werden, wenn ein oder mehrere Knoten entfernt wurden. Das Event enthält den Pfad zum Vaterknoten, sowie einen Array mit den entfernten Knoten. Zusätzlich muss das Event einen Array mit den ehemaligen Indizes der entfernten Knoten beinhalten. Diese beiden Arrays müssen aufsteigend sortiert sein.		Soll benutzt werden, wenn ein oder mehrere Knoten entfernt wurden. Das Event enthält den Pfad zum Vaterknoten, sowie einen Array mit den entfernten Knoten. Zusätzlich muss das Event einen Array mit den ehemaligen Indizes der entfernten Knoten beinhalten. Diese beiden Arrays müssen aufsteigend sortiert sein.
	Wird ein ganzer Unterbaum entfernt, muss die Methode nur für den Wurzelknoten dieses Unterbaumes aufgerufen werden.		Wird ein ganzer Unterbaum entfernt, muss die Methode nur für den Wurzelknoten dieses Unterbaumes aufgerufen werden.
	*treeStructureChanged()		*<code>treeStructureChanged()</code>
	Wenn die Veränderungen derart komplex sind, dass die anderen Methoden nicht mehr passen, wird diese Variante benutzt. Das Event enthält lediglich einen Pfad zu dem Knoten, der zuoberst in der Hierarchie der veränderten Knoten steht. Wenn man die Wurzel austauschen möchte, übergibt man einen Pfad der Länge 1, mit der neuen Wurzel.		Wenn die Veränderungen derart komplex sind, dass die anderen Methoden nicht mehr passen, wird diese Variante benutzt. Das Event enthält lediglich einen Pfad zu dem Knoten, der zuoberst in der Hierarchie der veränderten Knoten steht. Wenn man die Wurzel austauschen möchte, übergibt man einen Pfad der Länge 1, mit der neuen Wurzel.
	Diese Methode ist mit Vorsicht zu genießen, ein JTree wird einfach alles zuklappen (die Einstellungen gehen verloren). Wenn möglich, sollte man also die anderen 3 Methoden verwenden.		Diese Methode ist mit Vorsicht zu genießen, ein {{JAPI\|JTree}} wird einfach alles zuklappen (die Einstellungen gehen verloren). Wenn möglich, sollte man also die anderen 3 Methoden verwenden.

	Der untenstehende Beispielcode zeigt ein TreeModel welches seinen Baum intern durch TreeNodes darstellt. Es gibt zwei Aktionen "Add" und "Remove". "Add" fügt allen selektierten Knoten ein Kind ein (durch die add()-Methode des ChangeableTreeModels), "Remove" entfernt alle selektierten Knoten.		Der untenstehende Beispielcode zeigt ein TreeModel welches seinen Baum intern durch TreeNodes darstellt. Es gibt zwei Aktionen "Add" und "Remove". "Add" fügt allen selektierten Knoten ein Kind ein (durch die add()-Methode des ChangeableTreeModels), "Remove" entfernt alle selektierten Knoten.