|
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<br />
{<br />
public partial class Form1 : Form<br />
{<br />
public Form1()<br />
{<br />
InitializeComponent();<br />
}<br />
<br />
private void button1_Click(object sender, EventArgs e)<br />
{<br />
string path = @"c:\testc.txt";<br />
try<br />
{<br />
<br />
StreamWriter textOut = new StreamWriter(new FileStream(path, FileMode.Create, FileAccess.Write));<br />
<br />
}<br />
<br />
catch(IOException ioe)<br />
{<br />
MessageBox.Show(ioe.Message);<br />
}<br />
StreamWriter textOut = new StreamWriter(new FileStream(path, FileMode.Create, FileAccess.Write));<br />
textOut.Write("test");
textOut.Close();<br />
}<br />
}<br />
}
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
|
|
|
|
|
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.
|
|
|
|
|
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 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.
|
|
|
|
|
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.
|
|
|
|
|
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");
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");
textOut.Close();
}
}
}
|
|
|
|
|
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.
|
|
|
|
|
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).
|
|
|
|
|
Thanks guys,
I sincerely appreciate the criticism and analysis. Problem solved.
thanks again,
stuntman
|
|
|
|
|
In the GridView_RowUpdating method, e.RowIndex returns null.
GridView1_RowUpdating(object sender, GridViewUpdateEventArgs e).
I put a datatable and stored the grid and now e.RowIndex returns correct value
Could not understand the theory. Am trying to find it.
Still, can somebody help me out if you already know?
Thanks
|
|
|
|
|
I have been trying to come up with a way to track the CPU% usage of applications that I have running on different machines in different locations. In some instances there are multiple copies of the application running on the same machine. I was hoping to use the performancecounter to get the cpu% for these applications. However, I cannot get accurate results from machines running multiple copies of the application because the instance or names of the processes are the same. For instance, if I have four copies of an application running on one machine, my results may look like:
appName 100%
appName 100%
appName 100%
appName 100%
When in reality it should be:
appName 1%
appName 2%
appName 100%
appName 4%
Here is the code that I was using. Does anyone have any suggestions?
<br />
public string CPUUsage(string workingDirectory)<br />
{<br />
string procName = ConfigurationManager.AppSettings["MonitorEXE_Name"];<br />
<br />
string cpuUsage = "0.00%";<br />
<br />
Process[] processes = Process.GetProcessesByName(procName);<br />
<br />
if (processes.Length > 0)<br />
{<br />
string thisProcessWorkingDirectory = workingDirectory + "\\" + procName + ".exe";<br />
foreach (Process process in processes)<br />
{<br />
if (process.Modules[0].FileName.ToUpper() == thisProcessWorkingDirectory.ToUpper())<br />
{<br />
Process processToMonitor = Process.GetProcessById(process.Id);<br />
<br />
using (PerformanceCounter pcProcess = new PerformanceCounter("Process", "% Processor Time", processToMonitor.ProcessName))<br />
{<br />
<br />
pcProcess.NextValue();<br />
System.Threading.Thread.Sleep(1000);<br />
cpuUsage = pcProcess.NextValue().ToString("f2") + "%";<br />
<br />
} <br />
}<br />
} <br />
}<br />
return cpuUsage;<br />
}
|
|
|
|
|
|
I'm populating a treeview with the following:
1 Main Parent Node
5000 Child Nodes
1 Sub Node for each Child Node
The function I'm using returns a TreeNode (the main parent node with all children etc) in less than 0.1 secs which is quite acceptable. Adding this node to the treeview takes around 2.4 seconds during which time the UI is locked.
Is there any way of speeding this up?
Dave
-- modified at 13:56 Friday 21st September, 2007
|
|
|
|
|
The only thing you can do is call BeginUpdate on the TreeView to stop it from redrawing itself on every change to the control. Then you add your nodes to it, then call EndUpdate to resume painting the control.
|
|
|
|
|
Thanks, but I already tried that and it actually added to the time as the function returns a single treenode but with a nodes.count property of 5000.
|
|
|
|
|
Were you calling it inside of a loop? You should really only call them once, right before you add the first node and after you have added the last one, not each time you add the node.
|
|
|
|
|
No, the function is only called once and returns the MainNode then just one TreeView1.Nodes.Add(MainNode);
Because MainNode already has child nodes it's all that is required - all the looping goes on when parsing the xml and this successfully creates the mainnode with all the children in less than 0.1 sec.
|
|
|
|
|
Depending on how you are actually building up the nodes, collect them in a List<TreeNode> collection first. Once you are done creating them, call AddRange instead of Add and pass in the list (you will need to call List.ToArray() to pass it in as AddRange only accepts arrays).
Using AddRange is considerably faster than calling Add repeatedly, especially for large amounts of adds.
As Dave mentioned, you should also call BeginUpdate and EndUpdate as well as SuspendLayout, ResumeLayout to prevent the UI from repainting after each add. (I don't think BeginUpdate, EndUpdate implicitly make the calls to SuspendLayout, ResumeLayout, but if they do you wouldn't need to call both explicitly.)
[modification at 17:01 Thursday 20th September, 2007]
The SuspendLayout, ResumeLayout calls won't actually buy you anything in this case. The BeginUpdate, EndUpdate are the ones you want to use.
[/modification]
|
|
|
|
|
Good answer. It's surprising how many people aren't aware of the performance benefits of AddRange.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Pete O`Hanlon wrote: Good answer. It's surprising how many people aren't aware of the performance benefits of AddRange.
Thanks. In some ways it's surprising, but I don't think it's clearly documented that AddRange has better performance for certain situations.
|
|
|
|
|
I'll certainly bear that in mind for other situations. I just tried it, and although it didn't help in this case, there was no extra overhead in terms of time and is potentially far more flexible.
|
|
|
|
|
Created a quick example code to see if this helps define my problem
class Tree
{
public static TreeNode Build()
{
TreeNode MainNode = new TreeNode("MainNode");
for (int i = 0; i <= 5000; i++)
{
TreeNode ChildNode = new TreeNode("ChildNode" + i.ToString());
TreeNode SubNode = new TreeNode("SubNode");
ChildNode.Nodes.Add(SubNode);
MainNode.Nodes.Add(ChildNode);
}
return MainNode;
}
}
private void Form1_Load(object sender, EventArgs e)
{
TreeNode MainNode = Tree.Build();
treeView1.Nodes.Add(MainNode);
}
|
|
|
|
|
Yes, the code sample helped clarify things. I would change the Build function so that it takes a reference to the TreeView and also makes use of the AddRange call to add the nodes. It would end up looking something like this:
public static void Build(ref TreeView treeView)
{
TreeNode mainNode = new TreeNode("MainNode");
List<TreeNode> childNodes = new List<TreeNode>();
for (int i = 0; i <= 5000; i++)
{
TreeNode childNode = new TreeNode("ChildNode" + i.ToString());
TreeNode subNode = new TreeNode("SubNode");
childNode.Nodes.Add(subNode);
childNodes.Add(childNode);
}
treeView.Nodes.AddRange(childNodes.ToArray());
} Depending on how you are actually creating the sub nodes, you may also want to do something similar and use a List<TreeNode> and AddRange to populate the Nodes collection of the childNode object.
This should give you better performance.
|
|
|
|
|
Created this below, a form with 2 treeviews a listbox and a button.
I think it's just the .net treeview control is just slow period! Unfortunately it's the only control that will suffice in the real application unless anyone knows a better (possibly free?) one.
Thanks for everyones time anyway.
public static TreeNode Build()
{
TreeNode mainNode = new TreeNode("MainNode");
for (int i = 0; i <= 5000; i++)
{
TreeNode childNode = new TreeNode("ChildNode" + i.ToString());
TreeNode subNode = new TreeNode("SubNode");
childNode.Nodes.Add(subNode);
mainNode.Nodes.Add(childNode);
}
return mainNode;
}
public static void Build(ref TreeView treeView)
{
TreeNode mainNode = new TreeNode("MainNode");
List<TreeNode> childNodes = new List<TreeNode>();
for (int i = 0; i <= 5000; i++)
{
TreeNode childNode = new TreeNode("ChildNode" + i.ToString());
TreeNode subNode = new TreeNode("SubNode");
childNode.Nodes.Add(subNode);
childNodes.Add(childNode);
}
treeView.Nodes.Add(mainNode);
treeView.Nodes[0].Nodes.AddRange(childNodes.ToArray());
}
private void button1_Click(object sender, EventArgs e)
{
treeView1.Nodes.Clear();
treeView2.Nodes.Clear();
listBox1.Items.Clear();
DateTime dtBuild1Start;
DateTime dtBuild1End;
TimeSpan tsBuild1;
DateTime dtBuild2Start;
DateTime dtBuild2End;
TimeSpan tsBuild2;
Application.DoEvents();
dtBuild1Start = DateTime.Now;
TreeNode MainNode = Build();
treeView1.Nodes.Add(MainNode);
dtBuild1End = DateTime.Now;
tsBuild1 = dtBuild1End - dtBuild1Start;
listBox1.Items.Add("Build1 in " + tsBuild1.TotalMilliseconds.ToString() + " milliseconds");
dtBuild2Start = DateTime.Now;
Build(ref treeView2);
dtBuild2End = DateTime.Now;
tsBuild2 = dtBuild2End - dtBuild2Start;
listBox1.Items.Add("Build2 in " + tsBuild2.TotalMilliseconds.ToString() + " milliseconds");
}
|
|
|
|
|
Hmmm...I actually just ran your sample application and your way took 409 ms while mine took 676 ms. That result bothers me for a couple of reasons:
- The times are very different. Granted, that is probably due to hardware differences, but I wouldn't have thought it would be that significant.
- The use of
AddRange should still be faster.
I made one tweak to your sample, which changed the times to be within ~30 ms of each other. After several runs, it was inconclusive as to which method was consistently faster.
The change I made was in the Build(ref TreeView) function and changed the following lines:
treeView.Nodes.Add(mainNode);
treeView.Nodes[0].Nodes.AddRange(childNodes.ToArray()); to
mainNode.Nodes.AddRange(childNodes.ToArray());
treeView.Nodes.Add(mainNode);
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
