[adn258]

So when trying to read from ffmpeg which is an open source application and uses stderr output the code below works successfully but it doesn't output any output to the text box until the process completes. Is there any way to have a program output what's happening AS IT'S RUNNING just as if you used the program normally only it outputs to your box etc.??


My second question is disposing of processes it does use the IDisposable interface so I figured I'd use using( in front of it? IS this a good or bad idea or does it matter with processes and does the process need to be closed first .Close() or does it still dispose? Thanks guys. The code I have is below

 using (var ffmpegproc = new Process
             {
                 StartInfo = new ProcessStartInfo
                 {
                     FileName = "ffmpeg.exe",
                     Arguments = this.TxtBxFFMPEGCmd.Text,
                     UseShellExecute = false,
                     RedirectStandardOutput = true,
                     RedirectStandardError = true,
                     CreateNoWindow = true

                 }
             })
            {
                using (StreamReader sr = ffmpegproc.StandardError)
                {
                    ffmpegproc.Start();
                    string output = sr.ReadToEnd();
                    this.TxtBxOutPutFFMPEG.Text = output;
                    ffmpegproc.WaitForExit();
                    ffmpegproc.Close();
                }
            }

[tlhIn`toq]

1) If the target application provides status update events then you can subscribe to them. Just like backgroundworker updates via the progresschanged event when you are threading. But if the target process doesn't provide some mechinism then you can't magically peer inside to see its inner workings.

2) using() is a good thing 99% of the time. As long as the developer of the target process did their job right, then when the object is automatically disposed of it should run its .Dispose() method.

[Skydiver]

Your call to StreamReader.ReadToEnd() is why all the output is being batch together. If you want "live" output from the stream, you may want to consider using BeginErrorReadLine() to get asynchronous reads from the standard error stream. I don't know if there is an effective way to poll the StreamReader without blocking.

[barbary]

The way your accessing the stream response will always make it appear as if the output all comes at the end.

What you need to do is read the stream a bit at a time as the process happends

while (sr.Peek() >= 0) 
  {
    this.TxtBxOutPutFFMPEG.Text += sr.ReadLine;  
  }

without knowing the return types its difficult to know if I have typed this correctely.

Hope it helps.

[barbary]

Skydivers answer is correct way to do this.

To update the textbox in the event you will need to do the update on the GUI thread.

Read that example and then come back if you need more help.

[adn258]

Thanks skydiver, toq, barberby you guys are amazing as usual. So I have working code here but I know I might be paranoid but should I be worried about the event? These events scare me and even though the Process gets disposed here the event is never undone with -= is that bad in this case? Would it be safe to just use a simpler lazy += delegate method?

I just want to know that this code is safe and why? I am getting better at when to dispose and undo close things etc. but events I'm still confused. Here's the code the textbox auto scrolls as it's added in the event and it appears to work fine

    private void BtnBeginVideoConvert_Click(object sender, EventArgs e)
        {
            using (var ffmpegproc = new Process
             {

                 StartInfo = new ProcessStartInfo
                 {
                     FileName = "ffmpeg.exe",
                     Arguments = this.TxtBxFFMPEGCmd.Text,
                     UseShellExecute = false,
                     RedirectStandardOutput = true,
                     RedirectStandardError = true,
                     CreateNoWindow = true
                 }
             })
            {
                ffmpegproc.ErrorDataReceived += new DataReceivedEventHandler(ffmpegproc_ErrorDataReceived);
                ffmpegproc.Start();
                ffmpegproc.BeginErrorReadLine();
                ffmpegproc.WaitForExit();
            }
            
        }

        //add output data
        private void ffmpegproc_ErrorDataReceived(object sender, DataReceivedEventArgs e)
        {
            this.TxtBxOutPutFFMPEG.Text += e.Data + "\n";
            this.TxtBxOutPutFFMPEG.Select(this.TxtBxOutPutFFMPEG.TextLength, 0);
            this.TxtBxOutPutFFMPEG.ScrollToCaret();
        }

[Skydiver]

If the lifetime of the event handler is longer than the lifetime of the object firing the events, in general you are okay and don't need to unregister for notifications. Garbage collection will work correctly.

[adn258]

Skydiver, on 16 August 2012 - 01:13 PM, said:

If the lifetime of the event handler is longer than the lifetime of the object firing the events, in general you are okay and don't need to unregister for notifications. Garbage collection will work correctly.

Right one thanks. So if I understand this correctly the ffmpegproc object in this case is diposed and the event handler lives on so that's what you mean the eventhandler is still there whilst ffmpegproc is disposed and therefore it's ok? Sorry just want to make sure I know what you're talking about.

[Skydiver]

Yes, it is okay exactly for that reason.

[Skydiver]

C# is meant to free you from having to worry about micromanaging objects and references, and let you focus on solving the problem at hand. You are coding C# as if you were writing C++ code. That's good in some ways because it means you are trying to understand what the machine is doing, but I think it is also distracting you.

Anyway, to help ease your mind, it may help to read and learn more about memory is handled and how the garbage collector works in C#: http://msdn.microsof...e/bb985010.aspx

[adn258]

Skydiver, on 16 August 2012 - 11:12 PM, said:

C# is meant to free you from having to worry about micromanaging objects and references, and let you focus on solving the problem at hand. You are coding C# as if you were writing C++ code. That's good in some ways because it means you are trying to understand what the machine is doing, but I think it is also distracting you.

Anyway, to help ease your mind, it may help to read and learn more about memory is handled and how the garbage collector works in C#: http://msdn.microsof...e/bb985010.aspx

So when using my above code with the event

ffmpegproc_ErrorDataReceived

every time the button is clicked for convert ffmpegproc_ErrorDataReceived is += event becomes active. Since it's the same name though every time does this make any difference or is that bad?

[Skydiver]

It's okay because the 'using' statement will make sure that the ffmpegproc is disposed, and as part of disposing, it should release an references to your registered event handler.

[[email protected]]

Just to be clear, calling Dispose() doesn't unregister your event handler.

Quote

ffmpegproc object in this case is diposed and the event handler lives on so that's what you mean the eventhandler is still there whilst ffmpegproc is disposed and therefore it's ok?

I think you are almost there, but that still seems slightly confused to me.

If there was a problem here with not unregistering the event handler methods (which there isn't in this case), it would be the fact that the act of subscribing to the event with += would add a reference to your Form object to the ffmpegproc object, meaning the ffmpegproc object would now be holding a reference to your Form object, thus preventing it from being garbage collected.

However, the reason this isn't a problem in this case is that the ffmpegproc object will fall out of scope when your code exits the using block, meaning it will no longer be reachable by your code, meaning it will become eligible for garbage collection.

The registered event handlers are still there after the ffmpegproc object falls out of scope, but the fact that the ffmpegproc object will be garbage collected in upcoming collections (along with the reference(s) to your form held by the object, registered event handlers etc) means it won't keep your Form object alive longer than it should be, and so it causes no problem.

Unregistering of client event handlers doesn't typically have anything to do with calling Dispose().

This post has been edited by [email protected]: 09 December 2012 - 11:23 AM

[adn258]

[email protected], on 09 December 2012 - 11:15 AM, said:

Just to be clear, calling Dispose() doesn't unregister your event handler.

Quote

ffmpegproc object in this case is diposed and the event handler lives on so that's what you mean the eventhandler is still there whilst ffmpegproc is disposed and therefore it's ok?

I think you are almost there, but that still seems slightly confused to me.

If there was a problem here with not unregistering the event handler methods (which there isn't in this case), it would be the fact that the act of subscribing to the event with += would add a reference to your Form object to the ffmpegproc object, meaning the ffmpegproc object would now be holding a reference to your Form object, thus preventing it from being garbage collected.

However, the reason this isn't a problem in this case is that the ffmpegproc object will fall out of scope when your code exits the using block, meaning it will no longer be reachable by your code, meaning it will become eligible for garbage collection.

The registered event handlers are still there after the ffmpegproc object falls out of scope, but the fact that the ffmpegproc object will be garbage collected in upcoming collections (along with the reference(s) to your form held by the object, registered event handlers etc) means it won't keep your Form object alive longer than it should be, and so it causes no problem.

Unregistering of client event handlers doesn't typically have anything to do with calling Dispose().

This is very helpful and yes I'm getting close to understanding this all and it's thanks to people like you. So basically what you're saying is that since the event handling is being subscribed WITHIN The using block it too will be garbage collected automatically and unsubscribed with the ffmpegproc when ffmpegproc leaves it's scope out of the using block? So there is no need which was my guess to unsubscribe -= the ffmpegproc event?

[[email protected]]

Using statements have nothing to do with event subscriptions. If you didn't use the using statement, as so:

Spoiler

        private void BtnBeginVideoConvert_Click(object sender, EventArgs e) {
            var ffmpegproc = new Process() {
                StartInfo = new ProcessStartInfo {
                    FileName = "ffmpeg.exe",
                    Arguments = this.TxtBxFFMPEGCmd.Text,
                    UseShellExecute = false,
                    RedirectStandardOutput = true,
                    RedirectStandardError = true,
                    CreateNoWindow = true
                }
            };
            ffmpegproc.ErrorDataReceived += new DataReceivedEventHandler(ffmpegproc_ErrorDataReceived);
            ffmpegproc.Start();
            ffmpegproc.BeginErrorReadLine();
            ffmpegproc.WaitForExit();
        }

the result, in terms of the event subscription, would be exactly the same, because the ffmpegproc object will still fall out of scope, and become unreachable from your code at the end of the BtnBeginVideoConvert_Click.

A using statement ensures Dispose() is called. That's all. Further, Dispose() is totally unrelated to the event subscription you made. Finally, Dispose() usually has only, at best, an indirect effect on garbage collection.

Calling Dispose() does not cause garbage collection to occur (unless someone explicitly coded it to do so, using GC.Collect()), or magically allow the object to be garbage collected. Dispose() is actually largely unrelated to garbage collection. Dispose() is about freeing resources that the garbage collector has no knowledge of how to free (file handles, database connections etc). Remember, garbage collection deals only with raw memory.

In my opinion, you are best off separating IDisposable and garbage collection in your mind. They compliment each other as an all round means of resource management, perhaps, and therefore there is the occasional small overlap between them, but there is generally no direct relationship between the two.

This post has been edited by [email protected]: 09 December 2012 - 05:09 PM
Reason for edit:: Grammar