|
Now, I know how to send a filename to my application through the context menu with the registry.
AppName "%1"
But I want to send multiple filenames to my application.
Does anyone have any examples or hints as to what direction I should be looking do do this?
Thanks
|
|
|
|
|
I got this link from Marc Clifton's website. Looks interesting. Anyone have any experience with it? Would you recommend it?
TIA
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
The people in the lounge said I should google for the answer to a programming question but I do not know what search engine to use
|
|
|
|
|
I know people who've used it and like it. To be honest - I prefer to use the ones that I've rolled over the years, but they do seem to be solid enough.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Thanks Pete
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
The people in the lounge said I should google for the answer to a programming question but I do not know what search engine to use
|
|
|
|
|
No problem. I'm glad to help.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
