Question

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.

Answer 1

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.