I have a try catch block in the code that calls the second application.
Process represents a distinct operating system application. There is no way for exceptions to propogate across the process boundary.
However Process methods do have return values. Which you are ignoring.
Can you tell me what I can do to make certain the second assumption is not true
Insure that you can read both zero bytes and a very large number of bytes from stdout and stderr. And if you are not otherwise processing those for specific output then collect it somewhere so you can inspect it for errors and unexpected output.
Whenever you have a question regarding base framework things like this, you should first put that into google and then pick the link to the MSDN documentation. In most cases, this will be one of the first 3 links and is the best documentation to start learning from. Cheers. Delegates[^]
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
Please stand in front of my pistol, smile and wait for the flash - JSOP 2012
Voted 1 for (i) wrong forum (this has nothing to do with C#) and (ii) 'gimme codez' – we are not here to 'provide you solution' to a problem, that is what Google is for; CP is for asking specific questions when you are having a problem with an isolated aspect of your code.
i have write 5 diff words from 5 diff language into this string .
Looks to me like you have 5 different phrases, not words, and that each phrase is separate by a comma.
So first step is to break it into those parts.
After that you no longer have a problem of 5 different languages together. Instead you have a problem of identify a language (one language) given a string with one language. And then doing that five times.
I have worker threads writing to my GUI right now with the following code. My issue is that I'm getting MDA errors (ContextSwitchDeadlock and DisconnectedContext) during debugging and when I close the program, the child threads are still trying to write to controls that are nonexistent anymore, which generates errors as well.
I'm guessing I need to learn the proper way to use a delegate with multithreading/guis, so I was wondering if someone could provide some guidance and the proper/efficient way to communicate to the main form thread, from a child thread.
Using Invoke (synchronous) or BeginInvoke (asynchronous) to communicate with the UI thread is the correct approach. However, it is possible for a control to disappear while the background thread is processing, so you need to catch that exception (I couldn't find a way to guarantee that it can never happen).
I stumbled upon this link in googling and in one of the comments it was mentioned to set child thread to .IsBackground equaling true, so I did so (see brief code snip) and that seems to have eliminated the errors when closing my program. I'm glad the invoke/begininvoke are the correct way to do things, although I would still like to learn more about delegates and their proper usage.
My limited understanding of them now is that they are (at least in my project) an intermediary with the control on the main form, so that you can instruct the main thread/form thread to do something. It appears to have the ability to insert an item into the main form thread queue of what it is doing. Is that correct?
serviceMonitorThread = new Thread(new ThreadStart(serviceMonitor));
serviceMonitorThread.IsBackground = true;
If you set IsBackground, the worker thread will be killed when the main form is closed. That will solve the invoke-on-disposed-control issue but it is sometimes not what you want.
Delegates are simply typed function pointers. They are typically used to hook to events, which are some syntactic niceness around multicast delegates (i.e. the code calls what looks like one function, and several handler functions are run). They don't have anything directly to do with multithreading. Examples of non-threaded delegate usage include such obvious things as Click handlers on buttons (and all other UI events).
However, the way the Framework exposes threading functionality is either through Thread or BackgroundWorker. Thread takes a delegate to specify the method that should be run, and BackgroundWorker has several events which you can hook delegates onto.
It appears to have the ability to insert an item into the main form thread queue of what it is doing. Is that correct?
This is a decent description of the purpose of the Invoke or BeginInvoke methods. They ask the relevant thread to run a method (specified by a delegate) when appropriate.