Das Programm, welches ich gerade schreibe, soll sich sich Einstellungen des Nutzers merken.
Am praktischsten wäre es, wenn es die Einstellungen sich direkt in die executable Jar, von der das Programm auch gestartet wird, als Datei schriebe.
Das sich also im Archiv nicht nur die Klassen befinden sondern auch Konfigurationsdateien.
(Dadurch wäre es immer nur ein Archiv, das praktisch, portabel wäre)
Nein. Du kannst nicht in das gerade ausgeführte Jar-File schreiben.
Um Einstellungen auf dem System zu speichern nutzt man am besten Properties-Files oder den Java Preference Store.
Ich glaub' kaum. Denn während das Archiv ausgeführt wird ist es sicher vom Dateisystem zum Lesen geöffnet und kann deswegen nicht erneut zum Schreiben geöffnet werden.
Ausserdem ist es auch nicht sehr zu empfehlen während seiner Ausführung das Archiv mit der gesammten Anwendung zu verändern denn wenn dabei was schief geht ist die Anwendung dahin. Allgemeine Practice ist es im Archiv Standardeinstellungen zu platzieren, die geladen werden wenn im Userverzeichnis keine individuelle Einstellungsdatei gefunden wurde.
Ich hätte noch eine Frage wegen (J)MenuBar, die es nicht wert ist extra ein neues Thema zu eröffnen.
Ist es nach neustem standard jedem MenuItem eines Menus einer MenuBar, seinen eigenen ActionListener zu geben?
Das ergibt ernorm viel Code, weswegen ich es mit einem ActionListener gemacht habe, der switch hat und damit die entsprechenden Aktionen durchführt.
Ich glaub' ich würd's auch nur mit einem ActionListener machen jedoch nicht unbedingt mit switch. Ich würde die Switchanweisung hübsch in if, else if und else Blöcke auscoden.
Ich glaub' ich würd's auch nur mit einem ActionListeber machen jedoch nicht unbedingt mit switch. Ich würde die Switchanweisung hübsch in if, else if und else Blöcke auscoden.
Ja nee... das mach' ich auch so. Geht ja auch nicht anders. Ich dachte du redest von der actionPerformed-Methode... naja der Mensch denkt, Gott lenkt... der Mensch dachte, Gott lachte...
Vllt. gibt es aber noch einen Weg über 'ne Collection, indem man alle Items, Buttons usw. in einer solchen hält und dann, während man darüber iteriert die ALs dranhängt. Alledings wird der Code dadurch auch nicht viel kürzer, weil man schlicht [c]item.addActionListener()[/c] durch [c]<Collection> items.add(item)[/c] ersetzt.
Ok, die Vorteile habe ich beim durchlesen kapiert, aber die Anwendung nicht so wirklich.
Soweit wie ich die Texte verstanden habe, muss ich daher dann für jedes einzelne MenuItem noch seine eigene Klasse erstellen?
Java:
publicMenüObjekt1extendsJMenuItemimplementsAction{publicObjectgetValue(String key){//das was für MenüObjekt1 ist}publicvoidputValue(String key,Object value){//das was für MenüObjekt1 ist}publicvoidactionPerformed(ActionEvent e){//das was für MenüObjekt1 ist}}
Will heißen, wenn ich 20 JMenuItems habe, muss ich mir 20 Klassen erstellen die Action implementieren um da die entsprechenden anweißungen rein zu schreiben?
Oder wie mache ich das am kürzesten sinnvoll mit Action
Nimm die AbstractAction, dort sind die ganzen Methoden schon implementiert. Actions haben den Vorteil das sie wiederverwendbar sind. Du definierst die Action ein mal und kannst sie an mehreren Stellen verwenden. Du kannst natürlich auch anonyme innere Klassen dafür verwenden, das relativiert den Vorteil von Actions allerdings erheblich.
Nimm die AbstractAction, dort sind die ganzen Methoden schon implementiert. Actions haben den Vorteil das sie wiederverwendbar sind. Du definierst die Action ein mal und kannst sie an mehreren Stellen verwenden. Du kannst natürlich auch anonyme innere Klassen dafür verwenden, das relativiert den Vorteil von Actions allerdings erheblich.
Bedeutet aber trotzdem, dass ich für jeden einzelnes MenüObjekt eine Klasse von dem Abstract ActionListener ableiten muss??
Dazu hätte ich auch gleich noch ne Frage.
Werden beim Ausführen eines Javaprogrammes, alle Klassen in den Arbeitsspeicher geladen, oder liest das JRE wenn es eine Instanz erstellen soll jedes mal die Klasse auf der Festplatte nach?
Pro Classloader wird eine Klasse nur einmal geladen und zwar genau dann wenn sie zum ersten mal verwendet wird. Und keinesfalls solltest du aus falsch verstandener Optimierungswut versuchten möglichst wenige Klassen zu schreiben.
Pro Classloader wird eine Klasse nur einmal geladen und zwar genau dann wenn sie zum ersten mal verwendet wird. Und keinesfalls solltest du aus falsch verstandener Optimierungswut versuchten möglichst wenige Klassen zu schreiben.
Ob nun Action, AbstractAction, oder ActionListener. Eine Klasse brauchst du immer. Ob du nun n Klassen brauchst, oder eine instanz einer Klasse die viele Actions handelt, oder n Instanzen einer Klasse die jeweils eine Action handlen liegt bei dir.
