_Arvid_

Also zunächst einmal hättest du die Fallunterscheidung so gut wie gar nicht benötigt. Bei den beiden Teilen mit Fall-Nummer und Namen machst du im Grunde das Gleiche (fast jedenfalls). Hier kannst du also etwas zusammenfassen und dadurch einige Codezeilen sparen. Des Weiteren fiel mir auf, dass du der Liste jedes Mal einen neu erzeugten ListSelectionListener anhängst, wenn ein Kriterium vom Benutzer gewählt wird. Das ist wohl eher suboptimal. Die Listener jeweils einmal zu adden, sollte wohl reichen. Bereinige deinen Code entsprechend etwas. Vielleicht ergibt sich das eine oder andere Problem dabei von selbst. Auf jeden Fall wird es wieder ein Stück übersichtlicher und möglicherweise findest du dann die Fehlerursachen selbst. Anderenfalls melde dich nochmal. =) Zudem verstehe ich die Schilderung des dritten Problems nicht so recht. Klingt nach fehlendem Repaint. :confused:

Rufe doch vorher einfach die Methode clear() auf das DefaultListModel auf.

Die Ursache dafür ist eigentlich recht simpel. Schau dir mal die Implementierung der Methode equals(Object) in der Klasse String an. Dort findest du folgenden Code (von mir mal auf das Wesentliche gekürzt): public boolean equals(Object anObject) { if (this == anObject) { return true; } if (anObject instanceof String) { // hier der Vergleich der Zeichenketten // irgendwo dann noch ein "return true;" } return false; }[/PHP]Du machst bei dir einen Vergleich mit eben jener equals-Methode und übergibst als Parameter ein Zeichen ([font=Courier New]char[/font]). Durch das Autoboxing wird aus dem [font=Courier New]char[/font] zur Compile-Zeit ein Objekt der Wrapperklasse [font=Courier New]Character[/font] gemacht. Wie du in der obigen Methode erkennen kannst, wird der Teil für den eigentlichen String-Vergleich übersprungen, da der Parameter kein Objekt der Klasse [font=Courier New]String[/font] ist. Und schwupps landest du beim Bool'schen [font=Courier New]false[/font] als Rückgabewert. Ich denke, für die weitere Lösungssuche sollte das ein ausreichender Hinweis sein.

mit <%= %> kannst du den gewünschten wert direkt ausgeben. du musst nicht auf das out zugreifen oder sonstige spielereien. für die ausgabe eines strings, sagen wir "blubb", schreibst du in deine jsp-seite einfach ein: <%= "blubb" %> EDIT: println ist eine methode des streams out. methodenparameter übergibt man nicht mit einem punkt, sondern in klammern. also hätte es sowieso schon heißen müssen: out.println(array[1]) ...wobei hier zu beachten ist, dass in java der erste index die 0 ist, nicht die 1. wie auch immer - beim aufruf der mehtode println() solltest du darauf achten, nicht das gleichheitszeichen zu verwenden, weil hier ein wert verlangt wird, der dann direkt auf den stream geschrieben wird, die methode println() gibt aber keinen wert zurück. also du hast zwei möglichkeiten: <%= array[0] %> oder <% println(array[0]); %>

Such doch einfach mal in der Suchmaschine deiner Wahl nach "mvc java example", dann findest du unter Anderem folgende Erläuterungen inklusive Beispiel. Wo genau hast du denn deine Probleme? Kommst du irgendwo nicht weiter (wo genau)? Oder hast du Probleme beim Ansatz (was möchtest du machen und wie weit bist du damit)?

Ich hätte zwar auch ein Beispiel, allerdings ist das nicht gerade klein. Das jetzt extra "klein zu machen", ist mir zu aufwändig. Schau dir stattdessen mal dieses MVC-HowTo an. Zwar wurde es nie zum Ende geführt, aber es enthält zumindest für den Anfang mehr oder minder hilfreiche Codebeispiele. Ansonsten bleibt ja immernoch die Suchmaschine deiner Wahl... Im Übrigen gibt es einen erstklassigen von James Dempsey (er singt auch ganz andere Lieder, hier: ).

Aber selbstverständlich. Zum Einen gibt es sogar hier im Forum eine Linkliste für den Einstieg in die Java-Welt. Was da jedoch noch fehlt (hab ich auf einen schnellen Blick jedenfalls nicht sehen können), sind die Java Tutorials von Sun. Weiterhin kann ich folgende Linkliste empfehlen: Java Tutorials.

@Java_Neuling Ein gut gemeinter Rat (...im Sinne von konstruktiver Kritik, nicht im Sinne von bösen Anschuldigungen, versteht sich...) Ich habe den Eindruck, du solltest dich nochmal eingehend mit den Grundlagen der Java-Welt beschäftigen. Im günstigsten Fall hättest du noch von der Entwicklung von GUIs abgesehen. Wenn ich mich an meine Anfangszeit erinnere, waren da nur irgendwelche Ausgaben auf der Commandline und Eingaben von der selbigen. Exception-Handling ist ein unausweichliches Grundkonzept in der Entwicklung mit Java. Die scheint dir noch nicht so richtig bewusst zu sein, so scheint mir. Beginne an der Wurzel mit einer Programmiersprache (Grundlagen), nicht an der Spitze (z.B. GUI)! Des Weiteren habe ich das Gefühl, dass du grundsätzlich arge Probleme mit der Beschreibung deiner Probleme hast. Immer wieder scheinen helfende Forumsleser nachfragen zu müssen, wo deine Probleme liegen. Du solltest stets darauf achten, dass die Leser dieses Forums nicht sehen, was du siehst, nicht denken, was du denkst und auch nicht wissen, was du weißt. Zu schreiben, dass noch immer eine Fehlermeldung erscheint, mit der du nichts anfangen kannst, wird demnach niemand hier lösen können, ohne von dir noch zu erfahren, um welche Meldung es sich in welchem Kontext überhaupt handelt. Versetze dich also immer (!) in die Lage der Forumsleser, die dein Problem nicht kennen. Mit anderen Worten: Stell dich doof. Tu mal so, als ob du nicht die geringste Ahnung von dem hast, worum es in deinen Forumsbeiträgen geht. Lies deine Beiträge (noch vorm Abschicken, also in der Vorschau) durch, am besten mehrfach. Du wirst an manchen Stellen sicher schnell feststellen, dass Fragestellungen á la "Ich brauche Hilfe" nicht sehr aussagekräftig sind. Ferner wirst du dir selbst die Frage stellen: "Was will dieser Java_Neuling eigentlich und welches Problem hat er nun genau?" Also.... Probleme beschreibt man im Ideallfall wie folgt: Zusammenfassen, woran man überhaupt erstmal arbeitet. Anschließend darauf eingehen, woran man im Detail arbeitet (die Stelle, an der sich das Problem ergab, ohne das Problem selbst zu schildern). Dann erst eine genaue Beschreibung deines Problems machen (Welcher Fehler tritt unter welchen Umständen in welcher Form auf? Was genau funktioniert nicht? etc.). Daraufhin wird geschildert, was bereits alles unternommen wurde, um Abhilfe zu schaffen (Stichwort: Eigeninitiative). Im Anschluss dein Gesuch zusammenfassen, um dem Leser kurz und bündig nochmal die eigentliche Frage vor Augen zu führen. Vor allem aber solltest du eines bereits im Vorhinein erledigt haben: Suche selbst in den Weiten des Internets sowie auch in diesem Forum nach der Lösung eines ähnlichen oder gar des gleichen Problems. Lies dich schlau, ehe du dich an uns wendest! Es gibt hunderte von erstklassigen Tutorials, Hilfestellungen und Dokumentationen auf dieser Welt, die dir sehr viel schneller eine Lösung hätten bieten können, als es dieses Forum jemals könnte. So wäre beispielsweise die Frage nach der Meldung "Unhandled Exception" nicht nötig gewesen, ja sogar die Frage nach der Arbeit mit formatierten Textfeldern. Das Bild, welches ich bislang von dir vor Augen habe ist, dass du bei jedem Pups jemanden fragen willst, anstatt selbst mal zu schauen, was getan werden könnte/sollte. Gewöhne dir an, die Alternativen eines Forums zu nutzen. (Das soll keinesfalls heißen, dass du nie wieder im forum etwas fragen sollst! Das sollst du nur in denjenigen Fällen, in denen du wirklich keine Lösung findest - nirgends.) Bitte fasse diese "Standpauke" von mir nicht böse auf. Die ist echt lieb gemeint. Würde ich es böse mit dir meinen, hätte ich ganz sicher nicht die Zeit geopfert, so viel Text zu schreiben. Darüber hinaus hätte ich auch ganz andere Worte gefunden, um dir obigen Standpunkt klar zu machen. Betrachte es folglich als einen Wink mit dem Zaunpfahl. In diesem Sinne. Ändere deine Arbeitsweise ins Positive! Back2Topic... Zu guter Letzt noch zwei Worte zum Thema: Swing Tutorial Ja, das geht auch genauer: Formatted Textfield Ergänzend noch Folgendes: visuelle Übersicht der Swing-Komponenten

Mit if (String.matches(String)) {} lagst du schon mal gar nicht falsch. Aber was genau kriegst du bei Verwendung der Methode String.matches(String) nicht hin? Ich kann nur vermuten, dass dein regulärer Ausdruck nicht korrekt war oder dass der Code "drumherum" nicht ganz richtig läuft. Denn Sourcecodes wie private boolean fileMatchesRegExp(File aFile, String aRegularExpression) { return aFile.getName().matches(aRegularExpression); }sollten bei solch übersichtlichen Ausmaßen keine Probleme darstellen und einwandfrei funktionieren. Und diesen Spaghetti-Code mit der Schleife...? Eieiei...! Nagut, ganz sooo schlimm ist es nicht, aber das macht es noch lange nicht zu schönem Code. Es gibt sehr viel elegantere Lösungen. Finde und nutze sie. Lies dich durch die Tutorien der von Pinhead und mir gesendeten Links und du wirst fündig.

Hab grad keine Zeit, daher nur ganz kurz: Suche doch diesbezüglich mal in der Suchmaschine deiner Wahl nach "regular expression java", das erste Suchergebnis sollte bereits helfen können.

Wenn ich dich richtig verstehe, ist für dich an dieser Stelle "Reguläre Ausdrücke" ein Thema, mit dem du dich beschäftigen könntest. Mit regulären Ausdrücken, auch Regular Expressions genannt, kannst du Zeichenketten auf eben solche Merkmale untersuchen, wie zum Beispiel Teilstrings mit, die durch Sternchen * maskiert wurden. Weitere Infos findest du unter Anderem auf folgenden Seiten: Wikipedia-Artikel zu RegExp RegExp-Tutorial auf regenechsen.de Forensuche von fachinformatiker.de Ansonsten schau mal im Internetz nach "regular expressions", ergänzend hängst du noch ein "tutorial" ran.

Nee, ich meinte, du musst die Zeichenkennte direkt in die Scrollpane eintippen (meinetwegen einmal mit der Maus reinklicken für den Fokus), nicht ins Textfeld. Du siehst zwar nicht, was du tippst, aber die Markierung springt auf die entsprechende Datei oder das entsprechende Verzeichnis. Das ist so, als würdest du im Dateiexplorer von Windows "wild" drauf lostippen. Da wird auch die passende Datei entsprechend deinem Getippe selektiert.

nicht nötig, das funktioniert bereits.

Jaja, das hab ich schon verstanden. Wie man auf das besagte Textfeld zugreift, weiß ich nun wirklich nicht. Ich schätze, das wird auch nicht so leicht sein. Ein schneller Blick in die Sourcen des JFileChooser offenbarte mir, dass du da wohl etwas suchen werden musst. Daher bleiben dir wahrscheinlich nur die folgenden drei Möglichkeiten: - einen ganz eigenen FileChooser schreiben (dieser Aufwand wird sicher nicht lohnen) - den JFileChooser überschreiben, das Textfeld ausfindig machen und es entsprechend abfragen nach jeder Texteingabe - es einfach bleiben lassen Letzteres halte ich persönlich für die sinnvollste Sache, da das von dir gewünschte Dialogverhalten recht ungewöhnlich ist, wenn auch komfortabel. Ich denke, ein Benutzer wird auch damit klar kommen, wenn die Dateien nicht nach der im Textfeld angegebenen Zeichenkette eingegrenzt werden. Das ist schließlich das übliche Verhalten von Dateiauswahldialogen (zumindest wie ich sie kenne). Nebenbei erwähnt, kann man in der Scrollpane mit der Liste aller auswählbaren Dateien auch etwas eintippen. Zwar wird dadurch die Liste nicht eingegrenzt auf diejenigen Dateien, die mit der eingegebenen Zeichenkette beginnen, aber zumindest springt die Selektion auf die erste Datei, deren Name der Zeichenkette entspricht. Reicht dir das nicht schon? Puh, du stellst aber auch fragen...

Mhm, wüsste ich jetzt nicht, wie das geht. Die Sortierung der Spalten obliegt ja eigentlich dem Benutzer. Wie man die Sortierung (und ob man sie überhaupt) selbst machen kann, ohne dass der Benutzer etwas tun muss, kann ich nicht sagen. Sorry. Ansonsten schau dir mal das Swing Tutorial zum Thema JFileChooser an. Vielleicht findest du da ja noch etwas.

Wie jetzt - sortieren? Die angezeigten Verzeichnisse und Dateien sind in der Regel immer sortiert im JFileChooser, und zwar alphabetisch. Was will man mehr? Oder meintest du statt Sortieren das Gruppieren nach Dateitypen? Das wäre dann mit einem FileFilter möglich. Hierfür schau dir mal die Methode JFileChooser.addChoosableFileFilter(FileFilter) an. Anderenfalls müsstest du nochmal genau beschreiben, was du wie sortieren willst, was nicht bereits sortiert ist.

Abgesehen davon, dass zumindest ich dir mit meiner Abneigung und Unerfahrenheit zu JavaScript nicht hundertprozentig helfen kann, sicherlich aber einige andere hier, möchte ich erwähnen, dass dieses Thema viel eher in das Webdesign-Forum hätte gehören sollen. Warum? Java ist nicht JavaScript. Diese Info mal am Rande, um eventuell ein Missverständnis aus dem Weg zu räumen. Nichts desto trotz vermute ich, dass du die Variable pausebetweenimages auf einen kleineren Wert als 3000 setzen solltest.

Wie bereits erwähnt, welchen Editor du nimmst ist egal. Das solltest du nach eigenem Ermessen entscheiden. Hauptsache ist, dass der Editor dir gefällt, nicht uns. Meine Empfehlung ist dennoch UltraEdit, das ist meiner Meinung nach ein sehr guter Editor. Sofern ich mich nicht täusche, ist Notepad++ recht ähnlich (ich hab damit nichts Nennenswertes gemacht, nur mal kurz gesehen, daher keine verbindliche Angabe ). Zu den anderen von dir genannten Programmen kann ich keine Aussage machen, die habe ich zuvor noch nie benutzt. Also nochmal - nimm, was dir am liebsten ist. Probiere einfach alle Editoren durch und entscheide selbst. Des Weiteren sei erwähnt, dass du den Programmcode schreibst, nicht deine Editoren. Insofern ist die Qual der Wahl für den "richtigen" Editor teilweise überflüssig. Darauf kommt es wirklich nicht an. Was für den Anfang tatsächlich sehr sinnvoll sein kann, ist Syntaxhighlighting, das können die Tools wohl alle. Auto-Codevervollständigung kann äußerst nützlich sein, ist zu Beginn aber kein Muss. Mach dir also die Wahl nicht selbst so schwer.

Für den Einstieg empfehle ich keine Entwicklungsumgebung! Nimm auf jeden Fall einen Editor wie UltraEdit (oder wie wir bei uns im Betrieb sagen: die gute Ultra-Edith) oder sogar Notepad, sofern du auf Syntaxhighlighting und Auto-Codevervollständigung verzichten kannst. Sinn dahinter ist es, sich auf der Konsole mit dem Kompilieren deiner Sourcen und dem Verpacken der kompilierten Klassen zu JAR-Dateien auseinander zu setzen. Nichts anderes tun die integrierten Entwicklungsumgebungen, aber du willst ja schließlich alles über Java lernen, nicht wahr? Mit einer Entwicklungsumgebung wie Eclipse schießt du beim Einstieg in die Java-Welt sicher mit Kanonen auf Spatzen. Lass das erstmal lieber bleiben. Zumal das für einfache Java-Programme zum Lernen und Üben ohnehin viel zu überladen ist. Wenn du große Software-Projekte in Angriff nehmen möchtest, empfehle ich dir sogar eine ordentliche Entwicklungsumgebung, nicht jedoch im Moment. Wenn du so weit bist, kannst du dich von uns auch gerne bezüglich Alternativen zu Eclipse beraten lassen. Also nochmal in kurz: Nimm einen Editor, keine IDE. Welchen, ist im Grunde egal.

Zunächst einmal solltest du dir im Klaren sein, dass Webentwickler (zumindest aus meiner Erfahrung) grundsätzlich nicht so viel Geld verdienen wie "richtige Softwareentwickler" (bitte nicht falsch verstehen ) Zur Gehaltslage in München kann ich wenig sagen, außer dass dort wesentlich mehr Geld auf den Straßen rumliegt als hier im Norden. Also einfach zugreifen. Du kannst dir auch mal Folgendes ansehen: UniSPIEGEL - Gehaltsreport: IT-Fachkräfte räumen ab Beste Grüße Arvid =)

Suchmaschinen sind deine Freunde. Such doch mal nach "Java XML", dann findest du sehr schnell, was du wissen willst.

...Ohne mich jetzt genauer mit dem BorderLayout zu beschäftigen (es gibt durchaus bessere Layouts) und ohne wirkliche Kenntnisse von deiner Komponentenanordnung und der technischen -struktur zu haben, würde ich mal sagen, dass die Vermutung nicht dumm ist. Du kannst es ja mal mit anderen Layouts versuchen. Tatsächlich kann ich dir bezüglich der internen Frames nicht mehr weiter helfen. Etwas wirklich Ernsthaftes ist es damit bei mir noch nicht geworden. Ich habe bisher viel mehr auf sämtliche Panelarten gesetzt. Diese lassen sich hervorragend mit dem FormLayout anordnen. Des Weiteren waren interne Frames für mich nie richtig erforderlich. Damit klinke ich mich aus. Viel Erfolg noch!

...ah, ok. Für mehrere Dokumente also. Klar, ergibt Sinn für eine Textverarbeitung. Mit "Vorteile von internen Frames" meine ich zum Beispiel die Eigenschaft, im Gegensatz zu einfachen Panels verschiebbar, minimierbar, etc. zu sein. Und das ist ja genau das, was du offenbar nicht willst - diese Eigentschaft von internen Frames, sie verschieben zu können. Deswegen war ich etwas irritiert. Du wählt A, willst aber das zugehörige B nicht... Aber natürlich, da gebe ich dir Recht, ist es für eine Textverarbeitung recht sinnvoll, jedes Dokument in einem eigenen, internen Fenster anzuzeigen. Dann folgt trotzdem meine nächste Frage: Was ist so schlimm daran, sie verschieben zu können? Interne Frames nutzt man doch aus eben jenem Grund, dass der Nutzer die Anordnung selbst bestimmen kann. Fenster die man nicht verschieben kann, sind irgendwie überflüssig, das hätte man auch mit Panels machen können. Wie dem auch sei - eine Lösung deines Problems habe ich nicht. Du könntest aber auch über Alternativen nachdenken. Sicherlich könntest du für deine Zwecke auch JTabbedPane verwenden. Nur so eine Idee.

Mal so eine grundsätzliche Frage: Weshalb benutzt man interne Frames, wenn man die Vorteile von eben internen Frames nicht nutzen möchte? Was wäre das Problem bei schlichten JPanels gewesen? Wieso hast du dich dagegen entschieden?