Problem mit jformattedtextfields und jtable

[Draculajr]

ich hoffe ihr könnt mir dabei helfen
habe ein programm zur adressverwaltung geschrieben welches in der lage sein soll die eingaben in den textfeldern zu überprüfen bzw änderungen fest zu stellen und diese dann in die table eintragen

mein problem ist wenn ich zb in der spalte name einen eintrag mache und in der nächsten zeile den selbigen wieder eintrage an selber stelle übernimmt er dies nicht!!!

ich lade mal das ganze prog hoch und ja ich weiß das ichs noch weiter zerflücken sollte um nen besseren überblick zu bekommen,ist ja noch in arbeit
es ist zum größten teil auch dokumentiert, da es ein abschlussprojekt werden soll

ps: propertychange befindet sich in der startklasse maingui ganz unten^^
ka obs damit was zutun hat,finds vom logischen her richtig^^

hab ein wenig rumprobiert und scheinbar wenn ich mit e.getoldvalue und e.getnewvalue aufrufe, dann hat er wenn ich in der ersten spalte was eintrage zb a und in der zweiten oder ersten zeile in spalte eins dann zb b halt als alten wert a und neuen b
aber wenn ich in der zweiten zeile nochmal a eingebe hat er keinen alten oder neuen wert a,könnte es irgendwas damit zu tun haben das er denkt das es bereits drin enthalten ist?

 

[SlaterB]

falls noch aktuell:
je einfacher das Programm wäre, desto leichter ließe es sich prüfen,
du hast vielleicht nicht die Fähigkeiten den Fehler zu finden, gewiss ist dir aber der Fleiß möglich, das Programm zu vereinfachen,
weniger Klassen, weniger Code,

Blöcke wie

	String[] columnsGer = { "Vorname", "Nachname","Straße", "PLZ", "Ort","Geb.Datum", "Entfernen" };
	String[] columnsEng = { "Firstname", "Lastname","Street", "Postcode", "City","Birth.", "Delete" };
	String[] haschi = {"file","edit","speech","help","info","open","save","exit","newRow","deleteRow","speechGer","speechEng" };
	String[] gerEng = {"File","Edit","Language","Help","Info","Open","Save","Exit","Add Row","Del Row","German","English"};
	String[] engGer={"Datei","Bearbeiten","Sprache","Hilfe","Info","Oeffnen","Speichern","Exit","Zeile hinzu","Zeile löschen","Deutsch","Englisch"};

haben bestimmt nicht direkt mit dem Fehler zu tun,
teste in einer einfachen Tabelle mit nur einer Spalte,

die GUI muss nicht tausende Menüs haben, Lesen + Speichern von Datei kann gewiss (für diese Problembetrachtung) ganz raus usw.

 

[Draculajr]

danke^^
das ist immerhin noch in der beta und bins auc hschon am vereinfachen
habe mehr klassen welche erst aufgerufen werden wenn sie gebraucht werden nun und habe auch ein paar verkürzen und durch mehrdimensionale array ersetzt
somit fallen ein paar string klassen weg

ich geh ja die checkboxen durch und entferne die zeilen wo entsprechendes angeklickt wurde
soll ich also die tabelle zum testen auf die checkboxen beschränken?

 

[SlaterB]

fühle dich nicht zu sehr getrieben, dass du jetzt schon Tage warten musstest ist Strafe genug (wobei ich persönlich in der Zeit nicht da war),
hauptsächlich habe ich eh auf eine Rückmeldung gewartet ob das Problem noch offen ist,

wenn du jetzt schon bisschen weiteres eingespart hast und ne neue Version posten kannst, dann bitte,
dann kann ich sie mir anschauen

 

[Draculajr]

ok tu das,aber wie gesagt,ist noch im bau und als abschlussprojekt find ichs eig schon ganz nett wobei wir im unterricht nie bis zur gui kamen XD

nicht wundern wegen wegen table2array, ich mach das ja nit allein und musste nem klassenkammeraden nen array übergeben weil er sich nicht auskennt mit der table

problem besteht weiter,leider

 

[SlaterB]

9.6 KB im alten Zip, 9.6 auch im neuen, das ist wohl ein schlechter Scherz,
na ich will ich weiter dahingehend meckern, auch das Programm an sich ist für dich eine weitere Strafe..

du verwendest einen PropertyChangeListener, das ist ganz komisch, habe ich so im Einsatz noch nicht gesehen,
allerdings JFormattedTextField selber auch nicht unbedingt so oft, reicht kein einfaches JTextField wenn es doch eh nur um Strings geht?

ich habe bei mir den von dir genannten (unter diversen anderen, unter anderem NullPointerException, da das letzte Array-Textfeld null ist) Fehler behoben,
indem ich in MySelectionListener beim Setzen der Texte aus der der Tabelle noch
> textfelder.commitEdit();
eingefügt habe (hinter das else, auch ausführen wenn "" gesetzt wird),
damit wird der neue Text als Property-Änderung erkannt (Achtung, Listener in MainGui wird ausgeführt),
wenn du dann wieder dasselbe wie vorher eintippst, wird das angenommen

damit commitEdit() funktioniert, musst du den Arraytyp auf JFormattedTextField[] anpassen, bisher nicht überall so

------

zwei ärgste Tipps allgemein:
- nie in einem Klassen- Methoden oder Variablennamen oder sonst irgendwo 'Class' aufnehmen, besonders aber keine Klassen so nennen,
ListenClass, ansonsten müsstest du konsequent alles so nennen: MainGuiClass, MySelectionListenerClass usw.
- wichtiger: nie NullPointerException oder ArrayIndexOutOfBoundException mit try/catch abfangen, sondern Fehlern auf den Grund gehen..

 

[Draculajr]

ich hatte ja versucht den fehler zu finden aber kam irgendwie auf keinen grünen ast

aus welchem grund nicht class nennen?

JFormattedTextfield hatte ich ja auch eig genommen weil ich noch wollte das das eingeben von ";" nicht möglich ist da sonst fehler beim speichern entstehen,könnte es allerdings auch abfangen und durch ein leerzeichen beim speichern ersetzen lassen,aber wollte es eig so das es bei der eingabe nicht möglich ist
der MaskFormatter sah anfangs praktisch aus nur fordert er das eine gewisse anzahl an zeichen eingegeben wird und nicht eine einfache maximale länge abgefragt wird

sollte ich beim einfügen der texte also auch commitEdit benutzen?

sollte ich den propertyChangeListener auslagern?

 

[SlaterB]

aus welchem grund nicht class nennen?

sagt nichts aus, reines Blahblah,
aus dem Grund aus dem du auch eine Klasse nicht sfofdzsiudhfsk nennen solltest

sollte ich beim einfügen der texte also auch commitEdit benutzen?

wieso 'auch'? und was ist dann 'einfügen'?
du sollst das an der Stelle machen an der du manuell die Textfelder änderst, in MySelectionListener, wie gesagt,
wenn du in der GUI Enter drückst, dann wird die Methode eh ausgeführt, so bin ich drauf gekommen

 

[Draculajr]

gut zu wissen,mein lehrer hat glaube weniger ahnung von der materie als du XD
der kam nit auf die idee und konnte mir nit wirklich helfen^^

naja,einfügen nit wirklich,meinte an der stelle wo ich die textfelder mit den inhalten fülle die an entsprechender stelle in der table stehen

hab da aber noch ein kleines prob^^
wenn ich ne zeile lösche bekomm ich ne arrayindexoutofbound oder indexoutofbound exeption und es wird die zeile erst beim zweiten mal gelöscht und in der gui sieht man dann enweder noch die zeile komplett oder er löscht nicht alle -.-

wüsste nicht wo dran es liegen könnte da ich ja eig die zeilen entferne
hab mal gerätselt und könnte es vllt was damit zu tun haben das die zeile noch angewählt ist dabei?
und die inhalte somit auch in den textfeldern stehen?

 

[SlaterB]

man darf Exceptions auch anschauen,
wenn du sie nicht gerade mit try/catch wegfängst und komisch behandelst, dann steht im StackTrace, WO sie aufreten,

wenn z.B. in MySelectionListener.valueChanged() dann kann dort eine Exception auftreten, weil main.getSelectedRow() aktuell -1 ist da keine Zeile selektiert ist,
das sind einfache Dinge die zu prüfen sind und dann eben bei -1 KEINE Werte aus der Tabelle abfragen

wenn eine Exception aus deinem Code heraus fliegt, dann nachschauen ob irgendwas null ist, oder -1


bevor du jetzt jeden einzelnen deiner Fehler in dem Programm fragst war das von mir die letzte Antwort

 

[Draculajr]

ich danke dir trotzdem vielmals,hast mir schon sehr geholfen
und ich wollte dich echt nicht nerven,sollte ichs getan haben nochmals entschuldigung
bin nur im mom ein wenig unter stress weil wir am donnerstag abgabe haben und iwie alles nicht so läuft wies eig soll -.-
die exeptions schau ich mir auch eig immer an,hatte sie nur erstmal mit try und catch aufgefangen weil ich wollte das das prog weiter läuft da keine direkte lösung einfiel,habs mir halt einfach gemacht^^ aber richtig wars auch wieder nicht,haste recht