Develop Reference

C#: Parallel forms, multithreading and "applications in application"

First, what I need is - n WebBrowser-s, each in its own window doing its own job. The user should be able to see them all, or just one of them (or none), and to execute commands on each one. There is a main form, without a browser, this one contains control panel for my application.
The key feautre is, each browser logs on to secured web page and it needs to stay logged in as long as possible. Well, I've done it, but I'm afraid something is wrong with my approach.
The question is:
Is code below valid, or rather a nasty hack which can cause problems:
internal class SessionList : List<Session> {
public SessionList(Server main) {
MyRecords.ForEach(record => {
var st = new System.Threading.Thread((data) => {
var s = new Session(main, data as MyRecord);
this.Add(s);
Application.Run(s);
Application.ExitThread();
});
st.SetApartmentState(System.Threading.ApartmentState.STA);
st.Start(record);
});
}
// some other uninteresting methods here...
}
What's going on here? Session inherits from Form, so it creates a form, puts WebBrowser into it, and has methods to operate on websites. WebBrowser requires to be run in STA thread, so we provide one for each browser. The most interesting part of it is Application.Run(s). It makes the newly created forms alive and interactive. The next Application.ExitThread() is called after browser window is closed and its controls disposed. Main application stays alive to perform the rest of the cleanup job.
When user select "Exit" or "Shutdown" option - first the browser threads are ended, so Application.ExitThread() is called. It all works, but everywhere I can read about "main GUI thread" - and here - I've created many GUI threads. I handle communication between main form and my new forms (sessions) with thread-safe methods using Invoke(). It all works, so is it right or is it wrong?
Is everything right with using Application.Run() more than once in one application? :) An ugly hack or a normal practice? This code dies if I start a WebBrowser from the session form thread. It beats me why. It works however if I start WebBrowser (by changing its Url property) from any other thread. I'd like to know more what is really happening in such application. But most of all - I'd like to know if my idea of "applications in application" is OK.
I'm not sure what exactly does Application.Run() do. Without it forms created in new threads were dead unresponsive. How is it possible I can call Application.Run() many times? It seems to do exactly what it should, but it seems a little undocumented feature to me. I'm almost sure, that the crashes are caused by WebBrowser component itself (since it's not completely "managed" and "native"). But maybe it's something else.

Is everything right with using Application.Run() more than once in one application? :) An ugly hack or a normal practice?
Some of both ;) This is perfectly acceptable, in that it will function as you are expecting, but it's not exactly a "normal practice."
I'm not sure what exactly does Application.Run() do.
Application.Run basically does a couple of things. First, it installs the property SynchronizationContext into the thread for Windows Forms to run properly. It then starts the windows message processing in that thread, which processes all messages from Windows going into the thread. This is what allows forms to work properly.
There's nothing particularly wrong with doing this, but it isn't a standard practice. Given your design goals, I do question whether this would be better served by just launching a separate process instead of trying to run each operation within a separate thread.

Getting list of all windows in current thread

I am starting a new UI-Thread in my WPF-application. Now I am searching a way to get a list with all windows in this thread - like I will get it for the main-thread with System.Windows.Application.Current.Windows.
Is there something in the .NET-Framework or does I have to implement it myself? When I have to implement it myself, perhaps someone have little bit of sample-code?

To quote MSDN:
A Window reference is automatically added to Windows as soon as a window is instantiated on the user interface (UI) thread; windows that are created by worker threads are not added. A Window reference is automatically removed after its Closing event has been handled and before its Closed event is raised.
By default, the first item added to the Windows property becomes the MainWindow.
This property is available only from the thread that created the Application object.
So it seems the windows created by worker threads are not hold in any collection automatically. I assume you create that window on the worker thread - so you should store a reference to it yourself for later access (you could do that in the Windows constructor by adding this to some window manager class)

Why are WinForms applications STAThread by default?

When you create an empty WinForms application with Visual Studio, the template has the STAThread attribute in the main application class.
I have been reading some docs about it, but I'm not sure if I understood it at all.
Really I have some questions about it:
Why is this attribute added?
What does it mean?
What happens if you remove this attribute?

To quote from an MSDN blog,
When the STAThreadAttribute is applied, it changes the apartment state of the current thread to be single threaded. Without getting into a huge discussion about COM and threading, this attribute ensures the communication mechanism between the current thread and other threads that may want to talk to it via COM. When you're using Windows Forms, depending on the feature you're using, it may be using COM interop in order to communicate with operating system components. Good examples of this are the Clipboard and the File Dialogs.

1. Why is this attribute added?
Because it is required by the ActiveX object model. And you can drop ActiveX controls on a WinForm (so it is there for compatibility) OR some .NET classes use native controls which require that attribute.
2. What does it mean?
It means the thread runs in the single-threaded apartment model.
3. What happens if you remove this attribute?
If the attribute is removed, the behavior is undefined. The program may fail at random, with sometimes sensible error messages. For example, things may work now, then break with a service pack.

3.What happens if you remove this attribute?
I just add a simple example which demonstrates the problem.
I created simple WinForms app with a button and an OpenFileDialog. On button click I run a thread which shows the openFileDialog. I launch the app with and without STAThread and results of clicking the button are the same - it throws the exception "Cross-thread operation not valid: Control 'Form1' accessed from a thread other than the thread it was created on".
It looks as if there is no difference. But no.
Then I changed showing the openFileDialog by calling the method below:
private void ShowOFD()
{
if (InvokeRequired)
{
BeginInvoke(new Action(ShowOFD));
return;
}
openFileDialog1.ShowDialog(this);
}
With STAThread it works fine as expected. Without STAThread it throws the exception:
"Current thread must be set to single thread apartment (STA) mode before OLE calls can be made. Ensure that your Main function has STAThreadAttribute marked on it. This exception is only raised if a debugger is attached to the process".
Then I launch the app several times without debugger (detached from visual studio). One time the app just silently closed, another time the app closed with the message "vshost has stopped working"

It means that Windows Forms programs use a single-threaded apartment state. MTA and free threaded apartment states are not supported.

Open InternetExplorer COM object to do some automation using Wating from WPF app, but keep UI responsive. is this possible?

I have an app that runs a process which needs to open an internet explorer, go to an url, and do some stuff there, input some data, and return.
This usually takes a while (several pages that need to be filled, doesn't matter). The problem is, while this process is being done, the calling app (a standard wpf app) UI is unresponsive/frozen. When the process returns, i have some info that i need to set in one of the WPF app's objects
The main problem is that since IE needs to be called from within an STA thread, if I try to call it from within the dispatcher asynchronously or synchronously, for some reason the UI is blocked (i have tried with different DispatcherPriority-es but didn't get lucky).
If i start a new BackgroundWorker, that thread is in MTA mode (and i can't switch it back), so there's a problem and i have an exception
I'm really lost here, could anyone put some light into this? maybe what i want to do is simply not possible.

Have you tried creating your own background thread (not relying on BackgroundWorker), and set its ApartmentState to STA?

Using Invoke with a UI element that extends Application Context?

I have a taskBarIcon element extending Application Context from which my entire UI is designed. This is because the original functionality of the application was to run a background process and simply provide the icon as a confirmation that the app was running.
However, I am now adding additional functionality in the form of a menu that may be accessed by right clicking the icon, and since the core functionality is running on one thread, and the icon on the main thread, I am having issues accessing the icon in the simple case of needing to display a notification bubble. There are no other points at which the two threads may be accessing the same memory, so synchronization is not really an issue.
I am used to Java, in which this process is far simpler. I've read the articles I can find regarding the Invoke-Delegate dance that C# requires, but none are specific to an object extending Application Context. My current implementation is far too unpredictable to be production safe.
My question is this: How do I send the message to the other process to display the notification bubble, without disturbing the accessibility of the menu? Specifically, a simple example with a UI class extending Application Context and a class on a separate thread calling the invoke method would be very helpful.
I really appreciate any help!
badPanda

You could just as well use a SynchronizationContext object that you assign to SynchronizationContext.Current on the same thread that you create the notification bubble. You would then pass your SynchronizationContext object into whatever component the menu is on and it would use context.Send(....) to send a message. Or, if you have access to the notification bubble component or the form it's on, you could do form.Invoke((MethodInvoker)delegate {....});