Creating Form1 txt file, to use in Form2 (HangMan)

Crystas

New member
Joined
Sep 13, 2021
Messages
1
Programming Experience
Beginner
I'm stuck...

Form1:
I created an easy Form with Name, LastName and Age.
I save the FirstName and LastName in a log.txt file and i want to use it in Form2, but i can't get it to work.
Here is the part of the code that i save the First/Last name.

Form1:
private void btn_next_Click(object sender, EventArgs e)

        {
            

            // use Path.Combine to combine 2 strings to a path
            File.WriteAllText(Path.Combine("log.txt"), txt_firstname.Text + " " + textBox2.Text);

            if (txt_firstname.Text == "" || textBox2.Text == "" || textBox1.Text == "")
            {
                MessageBox.Show("Please fill all the form fields!");
                return;
            }
            else
            {
                Galgje myForm = new Galgje();
                this.Hide();
                myForm.Show(this);

            }
        }

Form2:

Here is the part where i keep changing things,
But if it wants to load the log.txt file it can't find it because it isn't created yet, but i want to use the name that the user use in log.txt
And that man is hanging alot in my tests and will get the message to the directory.log.txt but it doesn't show the words.
ATM i only have:

Form2:
private void button1_Click(object sender, EventArgs e)
        {
                //Ended here need to fix it
                target = Path.Combine(Directory.GetCurrentDirectory());
        }
 
Why do you even need to get the current directory if you saved your "log.txt" to the current directory in your first form? Wouldn't it make more sense just to use the analog of WriteAllText(): ReadAllText()?

Anyway, your current approach of using a file to transfer data between two forms is a really poor idea. Later the more data you write into that file, that would mean that you would need to parse the data to get the original pieces that went into it. It would be far better to pass in the needed data into the constructor for the other form. Unfortunately, if you are addicted to using the WinForms Designer, it doesn't really support having forms with constructor parameters. So at that point, you'll be force to pass in the needed data as properties on the child form.
 
Designer, it doesn't really support having forms with constructor parameters. So at that point, you'll be force to pass in the needed data as properties on the child form.
I don't really know where that is coming from. The user code file already includes a constructor, e.g.
C#:
public Form2()
{
    InitializeComponent();
}
You can simply edit that, e.g.
C#:
public Form2(string data)
{
    InitializeComponent();
    
    // Use data here
}
or add a new constructor, e.g.
C#:
public Form2()
{
    InitializeComponent();
}

public Form2(string data) : this()
{
    // Use data here
}
I have a bit of an idea that, at some stage, the first option may not have worked well because the designer required a parameterless constructor but, if that was the case, it no longer is. I just tested to check. The second option would always have worked.
 
I was using VS2005 and VS2008. WinForm Designer was never happy when I tried to change the constructor to take parameters. (It was also unhappy when I tried to do inheritance.) Given that with those versions of VS also had the WinForms Designer randomly crashing, I pretty much stopped using the WinForms Designer and just started writing my forms by hand. Good to hear that MS has fixed the inheritance as well as the constructor with parameters issue.
 
You certainly should not be using files to communicate between forms in the same application. Forms are objects, so you get data into and out of them in exactly the same way as you do any other objects. You should read this. There are three parts, so read all three. The last is the most important but the first two are good for background.

That aside, your original code makes little sense. You seem very keen on Path.Combine with no understanding of how it works. The whole point is to combine multiple partial paths into a single full path. Both here:
C#:
File.WriteAllText(Path.Combine("log.txt"), txt_firstname.Text + " " + textBox2.Text);
and here:
C#:
target = Path.Combine(Directory.GetCurrentDirectory());
you are only passing one partial path to the method, so you get out exactly what you get in. If the idea is to get a file path by combining a folder path and a file name then you need to provide both the folder path and the file name, e.g.
C#:
Path.Combine(Directory.GetCurrentDirectory(), "log.txt")
That said, you almost certainly should not be using the current directory. That will generally be the folder the application was run from but it won't always be and it can change while the application is running. If what you want is the path of the folder that the application was run from then you should be using Application.StartupPath in a WinForms app. That said, if you have deployed to the Program Files folder then the startup folder will likely be read-only. Windows provides multiple special folders that are intended for applications to write data to so use them. Some of their paths can be accessed using Environment.GetFolderPath, e.g.
C#:
var filePath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData), fileName);
If the file will be short-lived then you might even use a dedicated temp file, although they will have a random name.
 
WinForm Designer was never happy when I tried to change the constructor to take parameters.
If there ever was an issue, it was that the designer itself required a parameterless constructor because it used it to create an instance to display in the designer. I have a feeling that that was the case, as I alluded to previously, although now I'm not certain. I know that the WinForms designer has been rebuilt in recent VS versions so maybe they alleviated that issue then. You should still have been able to add extra constructors with parameters though. I know that I have in the past.
 

Latest posts

Back
Top Bottom