[Java] Txt-file uitlezen en in TextArea tonen

Ik ben nu bezig met een applicatie waarin ik tekst uit een txtfile wil lezen en tonen in een JTextArea.

Nu is dat op zich geen probleem als het allemaal binnen 1 class gebeurt, maar ik wil de TextArea in class 1 hebben staan en het txt-bestand lezen in class 2. De gelezen tekst moet dus naar de JTextArea in class 1 worden gebracht. Helaas blijft het tekstveld gewoon blanco De classes compilen wel en de applicatie start gewoon op.

In class 1 staat mijn JTextArea (genaamd displayNickname) gedeclareerd en geinitialiseerd.

public JTextArea displayNickname = new JTextArea();

In class 2 (extends class 1) staat:

displayNickname.setText(lines);
System.out.println(displayNickname.getText());

(Ik heb de rest van de code even weggelaten voor de duidelijkheid.)

Regel 2 is om te testen of displayNickname inderdaad de inhoud van lines (de string die ik uit het txt-bestand haal) krijgt. Dat is wel het geval. Maar regel 1 (die met setText dus) doet dus niet wat ik wil...Enig idee hoe ik de tekst van 'lines' toch in de JTextArea van class 1 kan krijgen?

Laat maar, heb het al opgelost. Voor mensen met hetzelfde probleem in de toekomst:

Mogelijkheid 1 was om het allemaal in 1 class te zetten, maar dat is geen optie als je het allemaal gescheiden wilt houden.

Mogelijkheid 2 was in class 2 een alternatieve textArea declareren en in de constructor als parameter meegeven, met als body een verwijzing naar zichzelf:

public Class2(JTextArea altTextArea){
     this.altTextArea = altTextArea;
}

die alternatieve textArea geeft je de data mee

altTextArea.setText(blabla);

Tot slot initialiseer je in class 1 de class 2 met het originele tekstveld als parameter:

class2naam = new Class2(orgineelTextArea);

Wat is Java toch een omslachtige klotetaal :\

[Chimera]

N00dles schreef op 20-03-2007 @ 21:05 :

Wat is Java toch een omslachtige klotetaal :\

Jij snapt 't idee van OO programmeren gewoon niet. Komt nog wel

Chimera schreef op 21-03-2007 @ 10:25 :
Jij snapt 't idee van OO programmeren gewoon niet. Komt nog wel

Ik snap er idd de fijne kneepjes niet van. Het principe van OO snap ik op zich wel, maar in de praktijk doemen hier en daar vraagtekens op...De communicatie tussen 2 classes is vaak een beetje uitproberen.

Maar wat ik nu dus doe is een tweede textarea formuleren in class 2, dat is toch omslachtig? Waarom kunnen classes niet gewoon rechtstreeks met elkaar data uitwisselen?

[Chimera]

N00dles schreef op 21-03-2007 @ 13:19 :
Maar wat ik nu dus doe is een tweede textarea formuleren in class 2, dat is toch omslachtig? Waarom kunnen classes niet gewoon rechtstreeks met elkaar data uitwisselen?

Ik snap echt je probleem niet. Vraag in class 2 gewoon een referentie naar de textarea op, en set dan gewoon de tekst? Met default access kun je er inderdaad niet bij, maar dat is logisch. Je kunt gewoon een methode getTextArea() maken die de textarea teruggeeft, en dan de text zetten. Dus:

class2instance.getTextArea().setText("Blaat");

Chimera schreef op 21-03-2007 @ 13:50 :
Ik snap echt je probleem niet. Vraag in class 2 gewoon een referentie naar de textarea op, en set dan gewoon de tekst? Met default access kun je er inderdaad niet bij, maar dat is logisch. Je kunt gewoon een methode getTextArea() maken die de textarea teruggeeft, en dan de text zetten. Dus:

class2instance.getTextArea().setText("Blaat");

Nou, mijn probleem was dus dat de variabele die in die class 1-textArea getoond wordt, wel de waarde meekrijgt, maar vervolgens niet vanuit class 2 in de textArea geset kan worden op een directe manier. Het veld bleef blanco.

En het werkt inmiddels dus ook wel, dus ik heb nu geen probleem meer. Maar ik vind het onnodig ingewikkeld omdat ik dus in class 2 een aparte verwijzing moest maken (dwz parameters doorgeven aan de constructor en blabla) ipv gewoon een eenvoudige textAreaNaam.setText(variabele);

[Chimera]

Ik snap niet wat er zo moeilijk aan is. Je hebt in ClassA een member variable member1. Als je die vanuit ClassB moet setten, de je toch instanceClassA.member1.setText("Blaat")?

Upload de code van die classes eens ergens want ik heb zo het vermoeden dat je jezelf hele verkeerde dingen aan 't aanleren bent.

Ik heb het idee dat je niet snapt wat een objectinstantie is. Waarom ben je hier eigenlijk mee bezig?

Chimera schreef op 21-03-2007 @ 17:34 :
Ik snap niet wat er zo moeilijk aan is. Je hebt in ClassA een member variable member1. Als je die vanuit ClassB moet setten, de je toch instanceClassA.member1.setText("Blaat")?

Upload de code van die classes eens ergens want ik heb zo het vermoeden dat je jezelf hele verkeerde dingen aan 't aanleren bent.

Ik heb het idee dat je niet snapt wat een objectinstantie is. Waarom ben je hier eigenlijk mee bezig?

Ik snap wel wat een objectinstantie is.

Button button1 = new Button(); maakt een instantie van het object Button, met de naam button1.

Ik doe dit trouwens voor school (niet voor mijn lol iig )

Ik zal de (werkende) code even posten die ik nu heb (alleen de relevante stukjes; imports, lege Actionmethods, panels waarop het textveld staat en rest van de GUI heb ik bewust weggelaten):

public class MainScreen extends JFrame implements ActionListener, WindowListener {

   public FileDialogClass fDialog;  
   public JTextArea displayNickName = new JTextArea();

   public static void main(String[] args){ 
      MainScreen fp = new MainScreen();
      fp.setVisible(true);

   }
   
   public MainScreen() {  
      fDialog = new FileDialogClass(displayNickName);
   } 

   public void buildLayout() {
   	displayNickName.setEditable(false);
   }    

   public void actionPerformed(ActionEvent e){
  	if(e.getSource() == menuFileItem2){
  		fDialog.openFile();
        }
   }
}

public class FileDialogClass extends JFrame implements WindowListener, ActionListener {
	
	JFileChooser fileDialogBox = new JFileChooser();
	BufferedReader inFile;
	JTextArea displayNickNameAlt;
	
   	public FileDialogClass(JTextArea displayNickNameAlt){
   		this.displayNickNameAlt = displayNickNameAlt;
	}
	
	public void openFile(){
   		fileDialogBox.addChoosableFileFilter(new FileDialogFilter());
		fileDialogBox.setAcceptAllFileFilterUsed(false);
		int returnVal = fileDialogBox.showDialog(this, "Open Project");
		File fileName = null;
		if (returnVal == JFileChooser.APPROVE_OPTION) {
           	fileName = fileDialogBox.getSelectedFile();
			try { 
				String line1;          	
				inFile = new BufferedReader(new FileReader(fileName));
				line1 = inFile.readLine();
                                displayNickNameAlt.setText(line1);
                                inFile.close();
		  	} 
    		        catch (IOException e) {
    			        System.err.println("Error in file: " + e.toString());
    			        System.exit(1);
   			}
            	
		
        	}
        	
        	fileDialogBox.setSelectedFile(null);
		
	}
}

[Chimera]

public FileDialogClass fDialog;
public JTextArea displayNickName = new JTextArea();

Waarom zijn deze public? Ik ben benieuwd wat er zou gebeuren als je dit zo zou laten staan en je code in zou leveren. Als je daar geen commentaar op krijgt, zou ik op zoek gaan naar een betere opleiding Member variabelen horen in princiepe ALTIJD private te zijn TENZIJ ze om een of andere reden geexposed moeten worden. Ik word al zenuwachtig als ik member vars zie met default access (dus niks ervoor, geen public of private), public is in jouw geval gewoon fout.

Verder is je opzet eigenlijk ook gewoon fout; JTextArea displayNickNameAlt is geen member van je filedialog class. Het idee achter OO programmeren is dat je objecten (Auto, Huis) hebt met onderdelen (Motor, Deur). Die TextArea is geen onderdeel van je fileopen dialog.

De meest nette manier om dit op te lossen zou zijn als volgt:

public class MainScreen extends JFrame implements ActionListener, WindowListener {

   public FileDialogClass fDialog;  
   public JTextArea displayNickName = new JTextArea();

   public static void main(String[] args){ 
      MainScreen fp = new MainScreen();
      fp.setVisible(true);

   }
   
   public MainScreen() {  
      fDialog = new FileDialogClass();
   } 

   public void buildLayout() {
   	displayNickName.setEditable(false);
   }    

   public void actionPerformed(ActionEvent e){
        String nickName;
  	if(e.getSource() == menuFileItem2){
  		nickName = fDialog.openFile();
                displayNickName.setText(nickName);
        }
   }
}

ublic class FileDialogClass extends JFrame implements WindowListener, ActionListener {
	
	JFileChooser fileDialogBox = new JFileChooser();
	BufferedReader inFile;
	
   	public FileDialogClass(){
	}
	
	public String openFile(){
		String nickName = null;   
   		fileDialogBox.addChoosableFileFilter(new FileDialogFilter());
		fileDialogBox.setAcceptAllFileFilterUsed(false);
		int returnVal = fileDialogBox.showDialog(this, "Open Project");
		File fileName = null;
		if (returnVal == JFileChooser.APPROVE_OPTION) {
           	fileName = fileDialogBox.getSelectedFile();
			try { 
				inFile = new BufferedReader(new FileReader(fileName));
				nickName = inFile.readLine();
                                inFile.close();
		  	} 
    		        catch (IOException e) {
    			        System.err.println("Error in file: " + e.toString());
    			        System.exit(1);
   			}
            	
		
        	}
        	
        	fileDialogBox.setSelectedFile(null);
                return nickName;
		
	}
}

Wat je openFile methode doet is een file openen en daar een stukje tekst uit lezen. Als je dat gedaan hebt, retourneert hij de tekst. Die openfile methode hoort helemaal niet te 'weten' waarvoor 'ie gebruikt wordt, dat een andere class die tekst in een TextArea gaat zetten is niet relevant.

Chimera schreef op 22-03-2007 @ 11:36 :
public FileDialogClass fDialog;
public JTextArea displayNickName = new JTextArea();

Waarom zijn deze public? Ik ben benieuwd wat er zou gebeuren als je dit zo zou laten staan en je code in zou leveren. Als je daar geen commentaar op krijgt, zou ik op zoek gaan naar een betere opleiding Member variabelen horen in princiepe ALTIJD private te zijn TENZIJ ze om een of andere reden geexposed moeten worden. Ik word al zenuwachtig als ik member vars zie met default access (dus niks ervoor, geen public of private), public is in jouw geval gewoon fout.

Verder is je opzet eigenlijk ook gewoon fout; JTextArea displayNickNameAlt is geen member van je filedialog class. Het idee achter OO programmeren is dat je objecten (Auto, Huis) hebt met onderdelen (Motor, Deur). Die TextArea is geen onderdeel van je fileopen dialog.

De meest nette manier om dit op te lossen zou zijn als volgt:

Wat je openFile methode doet is een file openen en daar een stukje tekst uit lezen. Als je dat gedaan hebt, retourneert hij de tekst. Die openfile methode hoort helemaal niet te 'weten' waarvoor 'ie gebruikt wordt, dat een andere class die tekst in een TextArea gaat zetten is niet relevant.

Hehe, ik lees ook overal dat het standaard beter private kan zijn ipv public, omdat dat 'een goede gewoonte' is, maar waarom het nu beter is dan public begrijp ik niet. Immers, zolang een applicatie niet te groot wordt is het sowieso nog wel overzichtelijk, en zolang er geen conflicten tussen variabelen ontstaan, boeit het toch niet zo heel erg dat elke method overal bijkan? Sterker nog, het is voor mij makkelijker omdat ik me dan geen zorgen hoef te maken over de toegankelijkheid van een variabele.

Bedankt trouwens voor je aanpassing. Idd een stuk overzichtelijker zo. Ik denk dat ik zelfs die setText-regel niet in de actionPerformed() zet, maar in een aparte method binnen MainScreen.

[Chimera]

N00dles schreef op 22-03-2007 @ 13:17 :
Hehe, ik lees ook overal dat het standaard beter private kan zijn ipv public, omdat dat 'een goede gewoonte' is, maar waarom het nu beter is dan public begrijp ik niet. Immers, zolang een applicatie niet te groot wordt is het sowieso nog wel overzichtelijk, en zolang er geen conflicten tussen variabelen ontstaan, boeit het toch niet zo heel erg dat elke method overal bijkan? Sterker nog, het is voor mij makkelijker omdat ik me dan geen zorgen hoef te maken over de toegankelijkheid van een variabele.

Wat is volgens jou de grootte van een applicatie waarbij dat wel belangrijk is?

Wel eens van de term spagetthi-code gehoord? Dit is precies wat een dergelijke warboel verzoorzaakt: code die overal bij kan, waardoor er geen enkele structuur meer in zit. De reden dat deze regels zo 'streng' zijn is dat ze je aanleren goed te programmeren. Reken maar dat als je ooit nog een grotere applicaties begint, je er alleen maar profijt van hebt het de juiste manier aangepakt te hebben.

Of een methode al dan niet ergens bij kan is niet iets waar een programmeur zich zorgen over hoeft te maken. Waar je je zorgen om moet maken is dat je je code 6 maanden later nog snapt, en dat anderen die jou werk over moeten nemen later dit ook doen. Ik ben vroeger in QBasic begonnen (niet tijdens m'n opleiding, gewoon voor de knutsel ), en ik heb ooit een keer een spelletje gemaakt, en nu ik die code teruglees snap ik er echt geen zak meer van.

Met dergelijke code was je hier niet je proeftijd doorgekomen nl.

N00dles schreef op 22-03-2007 @ 13:17 :

Bedankt trouwens voor je aanpassing. Idd een stuk overzichtelijker zo. Ik denk dat ik zelfs die setText-regel niet in de actionPerformed() zet, maar in een aparte method binnen MainScreen.

Lijkt me een prima idee, ik had geen zin om zelf te veel wijzigingen te gaan maken

Chimera schreef op 22-03-2007 @ 13:39 :
Wat is volgens jou de grootte van een applicatie waarbij dat wel belangrijk is?

Wel eens van de term spagetthi-code gehoord? Dit is precies wat een dergelijke warboel verzoorzaakt: code die overal bij kan, waardoor er geen enkele structuur meer in zit. De reden dat deze regels zo 'streng' zijn is dat ze je aanleren goed te programmeren. Reken maar dat als je ooit nog een grotere applicaties begint, je er alleen maar profijt van hebt het de juiste manier aangepakt te hebben.



Of een methode al dan niet ergens bij kan is niet iets waar een programmeur zich zorgen over hoeft te maken. Waar je je zorgen om moet maken is dat je je code 6 maanden later nog snapt, en dat anderen die jou werk over moeten nemen later dit ook doen. Ik ben vroeger in QBasic begonnen (niet tijdens m'n opleiding, gewoon voor de knutsel ), en ik heb ooit een keer een spelletje gemaakt, en nu ik die code teruglees snap ik er echt geen zak meer van.

Met dergelijke code was je hier niet je proeftijd doorgekomen nl.



Lijkt me een prima idee, ik had geen zin om zelf te veel wijzigingen te gaan maken

Een applicatie met meer dan 10 classes heeft wel baat bij een dergelijke structuur van private en public variabelen. Bij minder dan 10 lijkt het me niet zo heel broodnodig. Voor het doen van grootschalig programmeren is het wel handig om meteen die gewoonte aan te leren. Maar reken er niet op dat ik na mn opleiding verder ga daarin

Spaghetti-code is wel een voor zichzelfsprekende term ja. Maar goed, mijn code is nog wel begrijpelijk, al zeg ik het zelf.

En in mijn opleiding (Mediatechnologie) is (Java)programmeren slechts een onderdeel, niet de hoofdmoot. De opleiding probeert van alles wat (techniek, vormgeving, bedrijfskunde) mee te pikken, en erg diep wordt er niet op ingegaan. Maarja, toch ontkom ik er niet aan...