How to start Web Browser in a separate Window

Question

1.00/5 (1 vote)

See more:

Still new to the concept of Threading.
Have a WIndows Form application which sends a xmlstring to the webbrowser which than performs some action on that.
But since every call may has different data, I would need to have it open a new WebBrowser on it's own for each call.
This is what I have, but it always starts in same Webbrowser window.

C#

private void StartNewWindowThread(Prozessval p)
        {
            try
            {
                newWindowThread = new Thread(() =>
                {
                    WebBrowser wb = new WebBrowser();
                    String data = "myval=" + ControlHelper.SerializeXMLString(p);
                    System.Text.Encoding encod = System.Text.Encoding.UTF8;
                    byte[] bytVal = encod.GetBytes(data);
                    wb.Navigate("myurl", "_Blank", bytVal, "Content-Type: application/x-www-form-urlencoded");

                    Application.Run();
                });

                newWindowThread.SetApartmentState(ApartmentState.STA);
                newWindowThread.Start();
            }
            catch(Exception ex)
            {                
                throw ex;
            }
        }

Thanks for any help.

Posted 1-Dec-14 22:58pm

WizTAK

Updated 2-Dec-14 18:12pm

DrABELL

v3

Add a Solution

Comments

BillWoodruff 2-Dec-14 20:52pm

Creating, opening, a bunch of WebBrowserControls is going to cost you a lot of memory and may perform like a snail ... depending on your hardware/CPU/memory resources.

Sergey Alexandrovich Kryukov 2-Dec-14 22:01pm

The question is not so trivial as it may seem, even though it is probably based on OP's misconception.
Please see my answer; chances are, you will see something you never tried (more than one UI thread), even though this is not what should help OP (what can help is just understanding :-).
—SA

BillWoodruff 2-Dec-14 22:05pm

I never assume anything is trivial even if it's a misconception: my parents often told me that I was a misconception :)

Sergey Alexandrovich Kryukov 2-Dec-14 22:50pm

:-)

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Answer 1 · 2014-12-02T15:59:00

Solution 1

It has nothing to do with threading. All .NET UI libraries work in one thread. More exactly, you can create an application which uses two different threads with two different instanced of UI (two or more), but to do so, each of those threads should start with Application.Start. Then you will get two different UI threads, pretty much independent from each other; you would be able to communicate between them via Invoke/BegingInvoke. This is a very exotic approach; for now, let's forget it.

Nothing prevents you from running several instanced of the class WebBrowser, except some performance cost Bill Woodruff mentioned in his comment to the question. You don't need several threading for that. To understand why, you need to understand the basics of event-oriented architecture.

—SA

Posted 2-Dec-14 15:59pm

Sergey Alexandrovich Kryukov

Comments

BillWoodruff 2-Dec-14 22:08pm

That's a very intriguing answer ! I have never seen an example of a .NET app with more than one UI Thread (which may be just an artifact of my only working with Win Forms ?). Care to say more on that ? Wonder if you might mean one APP with UI calling Process.Start on multiple-instances of another App that had no UI ?

A second thought: would it be possible for the OP to create and use a WebBrowser Control without "siting" it in some Container ... so there would be no visual UI ... ?

Sergey Alexandrovich Kryukov 2-Dec-14 23:08pm

This is indeed unusual and is almost never used, just because usually it's not needed. I actually came to do such experiments in one of my work where I developed an platform abstraction layer based on Mono, to cover Max OS X, due Mac's hostile relationships with "foreign" platforms. It was possible to embrace "native" Mac UI by having two UI with Mono: one if Forms, and another is just to support that crazy Mac menu, which is on top for all application, outside the rest of application's UI. In practice, if we needed two UI, one would use the starting thread of the application, and another one would require one extra thread to be created. And then one could add more threads using the same approach.

The idea is simple:
Say, you create two threads and two main windows. Thread should be STA for WPF, and whatever for Forms. In one thread, run Application.Run, and the same on another thread. Each of those threads can be its own kind of UI; say, one can be WPF, another Forms, or both of the same type. As I said, you can run some other UI, such as Mac OS X on Mac with Mono; I guess, it could be Qt or GTK+ as well. The two UI will have two different (kinda unrelated) main windows.

On top of that, you can delegate the calls from one UI to another, say, in response to events. If you delegate something to the Forms UI, you need to call either System.Windows.Control.Invoke/BeginInvoke or Dispatcher.Invoke/BeginInvoke (WPF dispatcher can work on Forms as well); for WPF, it always should be the dispatcher call. It works. I guess, this is more funny than practically useful, but you can legally do it for certain kind of applications.

(Applications with more than one top-level window, not counting modal ones, are usually bad, but I do have use of them in some rare-case applications. For example, I use my own mail program for personal use, and it has two independent parts: sender and receiver (SMPT and POP3 clients). Both their windows are "main" (semantically); in fact, one is technically main, but only by the historical reason; so I had to simulate their equal rights. They are both WPF, but, if I had a good reason (say, big working legacy code), I could make them in two different UI threads, say, one could be WPF and another Forms. So, this is a rare case where this approach could work practically.)

—SA

BillWoodruff 3-Dec-14 0:24am

I appreciate the thoughtful reply, Sergey. One alternative "architecture" I have experimented with in the past using WinForms is where there is one static "controller" class whose "start" method is called from Program.cs, and which manages as many open top-level Forms of varying pre-defined Types as the user cares to instantiate ... with the idea of expressing a kind of "all forms are created equal" metaphor.

It was an interesting experiment, but does kind of "go against the grain" of how Windows Forms apps are "meant" to be used.

My question would be how do you execute Application.Run in one thread without blocking the other ... as you may see I am not really informed about threading.

Sergey Alexandrovich Kryukov 3-Dec-14 1:16am

Thank you, Bill.

Just one note: what is "meant to be used" is no a law or a regulation for anyone. "Against the grain" can be totally wrong or right. It depends on what the grain is. I absolutely don't mean your personally, but many do serious mistakes just by naively assuming some divine wisdom in creators of some major OS or languages/compilers. In fact, those authors make fatal mistakes while successfully pushing products and standards/architectures to the market, do many things only to please the masses of really weak developers (just to earn more money and get more of the market share), and so on. Only the rational arguments are valid.

As to blocking the thread... I think you will see the answer to your own question if you think a bit more. How one threads can block another one? Some actions could block if they were synchronous, but threads are designed to avoid blocking. The answer lie in the nature of the architecture of the event-oriented OS UI layers and the multithreading nature of the OS. Let's consider the basic usual case: you develop two separate windowed application and run them in parallel. We all know it works. Now, these two UI are executed in separate threads, just because even the processes are separate. For the UI API, which factor is essential, separate threads or separate processes? Separate threads. The events are dispatched via a queue which belongs to a thread. (Remember PostMessage(Thread).) The role of process separation is the separation of address spaces, isolation of the application. Put those two threads in the same process, and you will get the same picture, plus the possibility to directly communicate between those UI threads (with the usual care), so such interaction could take the place of IPC...

—SA

BillWoodruff 3-Dec-14 0:25am

+5 a provocative and stimulating post

Sergey Alexandrovich Kryukov 3-Dec-14 1:16am

Thank you, Bill.
—SA