|
|
Thanks for the reply; I hadn't seen that particular example, but it is doing the same as all the rest.
myStreamWriter.WriteLine(inputText);
then
myStreamWriter.Close();
The "Console.Writeline" writes to the debugger console which also works for me...
I write to the non-debugger console here:
inputWriter.WriteLine("WHY DONT YOU WORK");
inputWriter.Close();
I'm at a loss as to why it won't just work, it seems to be doing the exact same thing as the 10 or examples I've looked at...
EDIT: Grammar
modified 14-Feb-13 10:05am.
|
|
|
|
|
I just tested that sample and it works fine. I would suggest you check some of the options you have selected to ensure none of them is conflicting with what you are trying to do. You could also take that working sample and modify it to use the command you wish to run and see what happens.
|
|
|
|
|
I'm not sure that we are trying the same thing here. I loaded that example into a new app, and it doesn't write to the console either. I also get an error on this line about a NullReferenceException, presumably as the buffer is empty?
inputText = Console.ReadLine();
if (inputText.Length > 0)
What "Settings" are you referring to when you said I should check the settings?
|
|
|
|
|
If I change the application to a console application I can now run it without it crashing, but it still doesn't hand data out to the programmers command prompt.
|
|
|
|
|
Well I'm not sure what you are doing wrong. I just copied the code from the link I gave you, then wrote another program that reads and writes to the standard input and output stream, and it all worked. Maybe the fault lies with the program that you are trying to execute; what exactly does it do?
|
|
|
|
|
The program we are trying to write into is just a CMDPrompt that has been written to access the programming functions of the AtmelAVR programmer through command line. The commands we need to send resemble the one below:
atprogram -t avrispmk2 -i isp -xr -d ATmega328 -v chiperase
I'd say that ya maybe its the program, but we can't write into the windows command prompt (cmd.exe) either... The only place we can write to is the console debugger prompt.
|
|
|
|
|
In that case your approach is wrong. You need to set all these options into the StartInfo properties, or add them to the Process.Start method call, as described in the sample code here[^].
|
|
|
|
|
Interesting, This sounds promising. I'll make some changes and get back to you. Thanks for all the help.
|
|
|
|
|
ok, This all seems to point to the StartInfo settings, which I believe are correct already:
Process Temp = System.Diagnostics.Process.Start("CMD.exe");
Temp.StartInfo.UseShellExecute = false;
Temp.StartInfo.RedirectStandardInput = true;
Temp.StartInfo.RedirectStandardOutput = true;
Temp.StartInfo.RedirectStandardError = true;
Temp.Start();
Temp.StandardInput.WriteLine("Test");
Temp.Close();
So unless I've missed something, I don't think this is where the issue is.
|
|
|
|
|
I just tried this again from a Windows forms application and it still works.
|
|
|
|
|
Even something as simple as this doesn't put out any text...
string CommandText = "cd.. \r";
System.Diagnostics.Process.Start("CMD.exe", CommandText);
|
|
|
|
|
Nor would it, that just runs an independent process, which changes directory and immediately terminates without producing any output.
I have to say you are maybe getting yourself tied in knots here, by repeatedly trying everything you can think of, without really looking at what you should be doing. Think about what program you are trying to run, how it must be started, what input data it may read and what output it may produce. That should then determine how you need to start it, whether you need to feed it any input (beyond its initial parameters) and whether you should expect to read from its output stream.
|
|
|
|
|
Yeah, We are using a command prompt, or command processor as someone just called it (I may be using the wrong name for it). Then all re need to do is to literally send in a line (string) with a carriage return, read the text that comes in, and repeat based off of the text that comes back.
When I started it seemed easy enough to do, but it now seems that its not easy to feed text into a cmd window.
|
|
|
|
|
adam.m.b.nelson wrote: but it now seems that its not easy to feed text into a cmd window. Yes, it's perfectly easy, but you need to understand what is happening in that window, as I explained in an earlier post. I have not used the Process class before, but by following the rules, and understanding what goes on in the started application, I demonstrated that it works as documented.
|
|
|
|
|
Granted I am completely and utterly lost, but from the examples I have seen everything seems to be "right" but it still doesn't work.
Let's simplify this and say I simply want to write a line to the CMD window, from my GUI, and leave it sitting there staring at me. This program below should do that, NO?
private void btnKapow_Click(object sender, EventArgs e)
{
Process Temp = Process.Start("C:/Windows/System32/cmd.exe");
Temp.StartInfo.UseShellExecute = false;
Temp.StartInfo.RedirectStandardInput = true;
Temp.Start();
Temp.StandardInput.WriteLine("Test");
Temp.Close();
}
I'm completely out of my domain here, I'm an embedded programmer, and have built some GUI's in the past without an issue, but this single process is far more indepth than anything I have done before.
|
|
|
|
|
Not really. You start the command window, send it a (meaningless) word and then immediately close it. Maybe if you explain exactly what your program is supposed to do, I can offer some more suggestions. Explain:
- How is the program invoked manually from a command window.
- What, if any, further input commands do you need to type in to the program.
- What output is produced by the program on the command window, that you need to capture.
- What command, if any, is used to terminate the program.
The answer will not be forthcoming before tomorrow, but I'm sure it's possible to do it.
|
|
|
|
|
OK, I am starting to understand the issue. I had noticed it looked like there were two windows for an instant, but i attributed it to one of the Win7 window effects. So what is likely happening is there are actually two windows, and the one just opens and closes so fast that I can't see it?
To use the 'atprogram' the only route i can find into it is to use the StudioCommandPrompt located here "C:/Program Files (x86)/Atmel/Atmel Studio 6.0/extensions/Application/StudioCommandPrompt.exe". Once its open I need to run these commands:
atprogram -t avrispmk2 -i isp -xr -d ATmega328 -v chiperase
atprogram -t avrispmk2 -i isp -xr -d ATmega328 write -fs --values 7FD9FF
atprogram -t avrispmk2 -i isp -xr -d ATmega328 program -f Example.hex
After each step the window spits out some pass fail information.
There are alternative command line programming options, but that is the one I learned first.
This all makes a lot more sense now that I know the window is opening and closing very fast, it actually explains a lot. We're at the end of the day here, but first thing in the morning I'll try pumping in program commands like that and see if it works.
This whole time I saw an idle window sitting there, and assumed it meant the input hadn't been received.
Thanks for your help and patience, I will update tomorrow morning.
|
|
|
|
|
Slightly off topic, but given that you are (apparently) using Atmel Studio[^] to develop some embedded code application, what exactly is this C# program supposed to be for?
|
|
|
|
|
Yeah, AVR wasn't my decision, but that's another story. The C# GUI is part of an automatic test rig that tests all the functionality of our boards, then programs various aspects of the boards. It tests (currently) 7 boards at a time, but we will soon be expanding it.
Everything but the automatic programming is already working. I left it for last because I thought it was going to be the easy part :P
|
|
|
|
|
Sorry for the late response, I haven't been on in a while. The C# side was a computer based GUI to control the automated testing, and display results.
|
|
|
|
|
adam.m.b.nelson wrote: What "Settings" are you referring to when you said I should check the settings? Any of the properties of the Process , or its StartInfo .
|
|
|
|
|
Hmmm, I've looked through those settings pretty thoroughly. The problem definitely seem to be in the stream-writer. There are two of us working on this issue, on different machines and neither of can get text into a normal command prompt (but the debugger command prompt).
Can I see the code you wrote to test it? Maybe it will shine some light on our issue.
|
|
|
|
|
First of all test StudioCommandPrompt to find out if it is using the standard input, output and error streams correctly.
Here is an example of how it's done using the command processor, cmd.exe, which everyone should have.
At a command prompt enter
cmd < inputcommands.txt > stdout.txt 2>stderr.txt
This will start a new cmd.exe which will take redirected input from the file inputcommands.txt . Standard output will be redirected to the file stdout.txt and standard error to stderr.txt .
A suitable inputcommands.txt is
time /t
date /t
non-existent.exe
exit
Simple stuff: output the date, the time, try to exec an app that isn't there (to cause an error) and then exit.
Here is the contents of the output files
stdout.txt
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
XXXXXXX>time /t
17:47
XXXXXXX>date /t
14/02/2013
XXXXXXX>non-existent.exe
XXXXXXX>exit
stderr.txt
'non-existent.exe' is not recognized as an internal or external command,
operable program or batch file.
You would have to come up with a suitable set of inputs for StudioCommandPrompt and then run a similar test.
i.e. At a command prompt enter
StudioCommandPrompt < inputcommands.txt > stdout.txt 2>stderr.txt
It probably would be wise to run this test in steps
1) Check if your app will read from redirected input
StudioCommandPrompt < inputcommands.txt
2) If that's ok, test if output can be redirected
StudioCommandCommandPrompt < inputcommands.txt > stdout.txt
3) and separately test if error can be redirected, or possibly if the error stream is used at all.
StudioCommandPrompt < inputcommands.txt 2>stderr.txt
If it all checks out OK come back to me and we'll take it from there.
Alan.
|
|
|
|
|
Thanks Alan,
I'm going to start with something posted above, then I'll do this too. It'll take me a bit to make the changes.
|
|
|
|