.NET (Core and Framework)

15-Feb-11 2:07

Am I the only fool using .NET in here?... haha

In the process I´ve explained here the property Process::HasExited is true from the moment the process starts.

The same occurs with the method void extProcessWorkCompleted (System::Object^ /*sender*/, System::ComponentModel::RunWorkerCompletedEventArgs^ e) which is called when the process starts, and not when it actually finishes.

Has this something to do with the process´s code or am I doing something wrong?

Luc Pattyn15-Feb-11 3:10

15-Feb-11 3:10

piul wrote:
Am I the only fool using .NET in here?

I don't know.

piul wrote:
am I doing something wrong?

Most probably.

Hmmm | :|

Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum

Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.

piul15-Feb-11 3:20

15-Feb-11 3:20

Well... I was trying to make a joke, nothing else. I´m sorry if that dissapointed someone.

Ravi Sant15-Feb-11 3:42

Ravi Sant

15-Feb-11 3:42

No one is disappointed. It is NOT sensible to rewrite about same question.
And we have Message Type, which has Joke in it.
If you want to Joke, come and have a good joke at Lounge.

RobCroll15-Feb-11 4:20

RobCroll

15-Feb-11 4:20

Foolish,
The extProcessWorkCompleted event is raised when the process starts? Definitely someone has got it wrong. Couldn't see any MSDN documentation on extProcessWorkCompleted so I'm guessing it's you.

"You get that on the big jobs."

Accessing control from a different thread

Eddy Vluggen16-Feb-11 2:07

Eddy Vluggen

16-Feb-11 2:07

piul wrote:
The same occurs with the method void extProcessWorkCompleted (System::Object^ /*sender*/, System::ComponentModel::RunWorkerCompletedEventArgs^ e) which is called when the process starts, and not when it actually finishes.

Some executables finish immediately after spawning a child-proces. Can you compare the Process-ID of the executable that you started to the one that seems to be running?

I are Troll Suspicious | :suss:

piul14-Feb-11 23:18

Re: Accessing control from a different thread

14-Feb-11 23:18

I have a time consuming process that is called from a Windows forms application and run asynchronously in another thread, when the user clicks on runButton

extProcess = gcnew System::Diagnostics::Process;
extProcess->StartInfo = gcnew System::Diagnostics::ProcessStartInfo;
extProcess->StartInfo->RedirectStandardOutput = true;
extProcess->StartInfo->UseShellExecute = false;	//Necessary to redirect
extProcess->StartInfo->FileName = EXTPROC_EXE;
extProcess->StartInfo->CreateNoWindow = true;		//Don't open a new window for Process
extProcess->OutputDataReceived += gcnew System::Diagnostics::DataReceivedEventHandler (this, &Form1::StdoutHandler);
try
{
	extProcessThread->RunWorkerAsync();

The thread is launched and the standard output is read, to be shown in real time in a textBox in the main window

void extProcessThreadDoWork (System::Object^ sender, System::ComponentModel::DoWorkEventArgs^ e)
{
	extProcess->Start();
	extProcess->BeginOutputReadLine();
}
void Form1::StdoutHandler (Object ^ sender,
	 System::Diagnostics::DataReceivedEventArgs ^output)
 {
	 //Get text
	 textBox->AppendText (output->Data + "\n");
 }

The problem comes in this last line. An exception is launched "Control accessed from a thread other than the thread it was created on"
I do understand why, but I don´t know how to solve it...

piul14-Feb-11 23:41

Re: Accessing control from a different thread

14-Feb-11 23:41

Maybe using http://msdn.microsoft.com/en-us/library/ms171728.aspx

Simon_Whale14-Feb-11 23:59

Simon_Whale

14-Feb-11 23:59

You need to have a look at the invoke methods in the article shown by the other poster

MSDN: Look at the example at the bottom of the page[^]

As barmey as a sack of badgers

Dude, if I knew what I was doing in life, I'd be rich, retired, dating a supermodel and laughing at the rest of you from the sidelines.

Re: Accessing control from a different thread

Luc Pattyn15-Feb-11 3:14

External process stops everything else

15-Feb-11 3:14

This[^] explains it, however all examples are C# or VB.NET; same principles apply to C++/CLI.

Amd a BackgroundWorker's ProgressChanged and RunWorkerCompleted handlers don't have the cross-thread problem as they run on the thread that created the BGW, which normally is the main thread. That is one of the big advantages of BGW.

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum

Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.

piul14-Feb-11 0:31

14-Feb-11 0:31

I have a windows Forms application that calls a mathematical calculations .exe

superMinerProcess->Start();
superMinerProcess->BeginOutputReadLine();    //Start reading the output
while (!superMinerProcess->HasExited)
{    //...   }

If I set a breakpoint after the Start(); the program only reaches it after the process has finished. I don't understand... Any idea?

Luc Pattyn14-Feb-11 1:06

14-Feb-11 1:06

That is inconclusive. Where is this code located? what is in the while loop? what is it you are trying to achieve?

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum

Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.

piul14-Feb-11 2:25

14-Feb-11 2:25

The application is a dialog that runs a long mathematical calculation (the external process, an independent executable) when pressing a Run button. Hence, this code is located within the buttonRun_Click function.

while (!superMinerProcess->HasExited)
{
	if (processCancelled)
	{
		processCancelled = false;
		break;
	}
}

processCancelled is set to true in buttonCancel_Click. What I´m trying is to be able to kill the process when the user clicks on the Cancel button. I´ve tried writing superMinerProcess->Kill() in buttonCancel_Click but it won´t work because the Cancel button is just not clickable while the process is running.

Here´s the rest of relevant code of the process

superMinerProcess = gcnew System::Diagnostics::Process;
superMinerProcess->StartInfo = gcnew System::Diagnostics::ProcessStartInfo;
superMinerProcess->StartInfo->RedirectStandardOutput = true;
superMinerProcess->StartInfo->UseShellExecute = false;	//Necessary to redirect
superMinerProcess->StartInfo->FileName =  SUPERMINER_EXE;
superMinerProcess->StartInfo->CreateNoWindow = true;		//Don't open a new window for Process
//Arguments	
superMinerProcess->StartInfo->Arguments = getArguments();
superMinerProcess->OutputDataReceived += gcnew System::Diagnostics::DataReceivedEventHandler (&Form1::StdoutHandler);

Luc Pattyn14-Feb-11 2:37

14-Feb-11 2:37

OK, that is quite wrong for several reasons:

1.
the while loop has no blocking calls, so it will spin at full speed, consuming all cycles of one (perhaps the only) core. If you must have a polling loop like that, at least slow it down by inserting say Thread.Sleep(100);
However it is in general better to avoid a polling loop.

2.
It is not OK to halt the main thread like that, as the whole GUI will freeze. If e.g. another window pops up on top of your app, and then goes away again, your app won't repaint itself.

The correct approach would be:
- to have a separate thread (I suggest a BackgroundWorker) which launches the process, captures its output, and waits for its termination;
- to launch this thread from your button click handler (possibly also disabling said button, turning the cursor into a wait cursor, etc);
- to have a delegate dealing with intermediate results (maybe showing them in a ListBox);
- to have another delegate dealing with the termination of the process (restoring the GUI back to normal).

BTW: said thread would not need a polling loop on superMinerProcess->HasExited, as it could use superMinerProcess->WaitForExit()

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum

Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.

piul14-Feb-11 4:34