easy newbie question - SOLVED [modified]

shwaguy

I get the following error when running my code: "A local variable named 'textOut' cannot be declared in this scope because it would give a different meaning to 'textOut', which is already used in a 'child' scope to denote something else" namespace file_i_o { public partial class Form1 : Form { public Form1() { InitializeComponent(); } private void button1_Click(object sender, EventArgs e) { string path = @"c:\testc.txt"; try { StreamWriter textOut = new StreamWriter(new FileStream(path, FileMode.Create, FileAccess.Write)); } catch(IOException ioe) { MessageBox.Show(ioe.Message); } StreamWriter textOut = new StreamWriter(new FileStream(path, FileMode.Create, FileAccess.Write)); textOut.Write("test"); //*****THIS IS WHERE MY ERROR IS***** textOut.Close(); } } } If I put the "textOut.Write("test");" code in my try statement all is fine. I think this sucks; I found that I cannot reuse textOut anywhere else in my code, this just does not seem right! Please help and enlighten me. Many Thanks, Stuntman -- modified at 18:06 Thursday 20th September, 2007

lost in transition

You are declaring textOut twice in the same method. In your 'catch' block don't use StreamWriter in front of textOut.

God Bless, Jason
I am not perfect but I try to be better than those before me. So those who come after me will be better than I am.

Scott Dorman

First, please wrap large code blocks in <pre> tags, not <code> in order to preserve the formatting.

namespace file_i_o
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}

  private void button1\_Click(object sender, EventArgs e)
  {
     string path = @"c:\\testc.txt";
     try
     {
        StreamWriter textOut = new StreamWriter(new FileStream(path, FileMode.Create, FileAccess.Write));
     }
     catch (IOException ioe)
     {
        MessageBox.Show(ioe.Message);
     }

     StreamWriter textOut = new StreamWriter(new FileStream(path, FileMode.Create, FileAccess.Write));
     textOut.Write("test"); //\*\*\*\*\*THIS IS WHERE MY ERROR IS\*\*\*\*\*
     textOut.Close();
  }

}
}

The issue you are running into is due to the scoping rules of the language. If you want to do this, you need to declare the variable outside of the try block (StreamWriter textOut; or StreamWriter textOut = null;) and then simply "new" the variable in both places. Your code would end up looking like this:

namespace file_i_o
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}

  private void button1\_Click(object sender, EventArgs e)
  {
     string path = @"c:\\testc.txt";
     StreamWriter textOut = null;
     try
     {
        textOut = new StreamWriter(new FileStream(path, FileMode.Create, FileAccess.Write));
     }
     catch (IOException ioe)
     {
        MessageBox.Show(ioe.Message);
     }

     textOut = new StreamWriter(new FileStream(path, FileMode.Create, FileAccess.Write));
     textOut.Write("test"); //\*\*\*\*\*THIS IS WHERE MY ERROR IS\*\*\*\*\*
     textOut.Close();
  }

}
}

Scott.

—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]

Scott Dorman

It's not in the catch block. Take a look at my response to see the code in a formatted block. Even if it was in the catch block, it still wouldn't work because then textOut would be undefined in the catch block. In either case, the variable should be declared outside of the try.

Scott.

—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]

lost in transition

Scott Dorman wrote:

It's not in the catch block.

I guess my eyes got confused.

Scott Dorman wrote:

it still wouldn't work because then textOut would be undefined in the catch block

You right I wasn't paying much attention.

God Bless, Jason
I am not perfect but I try to be better than those before me. So those who come after me will be better than I am.

Scott Dorman

No worries. Whenever I see a post like that, at a minimum I will respond saying they should wrap the code in <pre> tags. Sometimes, as I did with this one, I'll reformat it for them (and anyone else that responds) and provide an answer.

Scott.

—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]

Pete OHanlon

I have to point out the obvious here. This code is really bad practice. In the try block, he initializes the textOut variable and if he gets an IOException he shows the message. Then, he initialises the try textOut variable in exactly the same way - if it didn't work once, is it really going to work again. Finally, the textOut.Close() should really be in a finally block.

Deja View - the feeling that you've seen this post before.

Scott Dorman

Absolutely! I missed those issues completely. The second calls to textOut probably either shouldn't be there or should be moved into the try block (with the redudant initialization removed).

Scott.

—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]

shwaguy

Thanks guys, I sincerely appreciate the criticism and analysis. Problem solved. thanks again,:) stuntman