|Written by Mike James|
|Wednesday, 23 February 2011|
Page 2 of 2
The next question is how to run LAME under our control?
The key to this is the use of the Process class. This can be used to start or gain control of any process and it offers a lot of control over how the process is run.
The only complication is that there are many different ways of achieving the same result. I’m going to use the simplest, if not the most concise. First add to the start of the program:
Following this we can create a new Process object in the second button’s click event handler:
private void button2_Click(object sender,
At this point we have a Process object which can be used to start or attach to a running process.
To do this you have to first set up the details of the process in its StartInfo structure. There are lots of fields in the StartInfo structure that you can use to fine tune the way the process is run and you should study the documentation carefully.
If the process is to be started from a file you have to set its filename, including any path if it isn’t in the same directory as the C# project (debug or release):
Lame.StartInfo.FileName = "Lame.exe";
Any command line arguments that you want to pass to the process can be stored in Arguments:
We also want to run the application without any window being created and we don’t want to use the shell to launch the program because we want to intercept any output it produces:
Lame.StartInfo.CreateNoWindow = true;Console applications like LAME write their output to the standard output stream, read their input from the standard input stream and send all their error message to the standard error stream.
Unfortunately LAME sends most of its data to the standard error stream – which can be confusing if you look for it on standard output!
To intercept the standard streams all you have to do is set the RedirectStandardx property to true:
As LAME doesn’t read from standard in there isn’t any need to redirect it.
Once you have specified all of the details of how you want to run the new process you can start it off:
The Start method spawns a new process and your program carries on running asynchronously.
Any output that the process generates will be redirected to stream buffers as you requested and it will sit there waiting for you to read it. The application may even wait for you to respond to its output before continuing, but LAME only produces status information as it codes the file to MP3. In this case all we have to do is read its output using standard error:
In this case the current status line which tells you how much of the file has been processed is simply placed in the textbox. This allows you to see the process as it is updated.
Notice the use of the DoEvents method to allow the form to be redrawn while the loop is running. In some cases you might need to arrange to read the input stream asynchronously to keep your application responsive – and there are methods BeginXRead and CancelXRead that allow you to do just this.
In the case of LAME the output comes fast enough not to need to do this. Finally we have to wait until the process is complete:
A more sophisticated front end would parse the data coming out of LAME and use it to display a bar chart of the percentage complete and intercept error messages. There are also lots of methods and properties of the Process class that you can use to check that everything is working and generally take tighter control over the way the application is run. Consult the documentation for the Process class - you will be pleasantly surprised at how much you can achieve.
A more sensible way to wrap an EXE so that other .NET programs can make use of it is to create a class that creates it and controls the way it runs and its interaction with the rest of the system. This has a few interesting problems and is the subject of another article coming soon.
|Last Updated ( Monday, 18 April 2011 )|