Some experience of browser Automation 2 WebBrowser control Ajax

The Last Post briefly discusses several methods of browser automation. Now discuss some of the problems in using WebBrowser controls. Basic operation is not detailed said, any online find a post or find a book are introduced. Here only to write points on the internet seems to be less people summed up the content, as well as some of their own practical experience.

1.ajax

First, the DocumentCompleted event has nothing to do with Ajax, because this event does not handle the Ajax requests that execute JavaScript after the page is loaded. Online can find the method, there are two main, one is to use the Onpropertychange event, casually find a reference link: https://social.msdn.microsoft.com/Forums/ie/en-US/ 5fe3e7a1-b3c7-4083-9a00-7a72bf833a9c/ajax-detection-in-webbrowser-control?forum=ieextensiondevelopment, The other is to use a timer.

Experience in practice is onpropertychange also bad use, timer more good. The essence of a timer here is delay. I generally have two ways to start a timer in the DocumentCompleted event handling code.

That

Private void webbrowser1_documentcompleted (object  sender, WebBrowserDocumentCompletedEventArgs e) {      timer1. Stop ();      Timer1. Start ();}

Here stop and start is just a personal habit, in many cases not necessary. However, if a timer has been started, you need to stop and start first.

The other is to start WebBrowser. Start the timer in the Navigate code:

Private void button1_click (object  sender, EventArgs e) {        webbrowser1.navigate ("Foo.com " );         timer1. Stop ();        Timer1. Start ();}

The person prefers the 2nd way, the reason is documentcompleted inside try not to use a lot of code, the main reason is that in some cases the DocumentCompleted event will be triggered multiple times, so if the situation is not properly handled, some code will be executed repeatedly, Cause unexpected results. However, the latter approach also has drawbacks, as it is not possible to start the timer after the DocumentCompleted event is triggered, and if the page loads slowly, the timer may start unnecessarily multiple times. So we still have to look at the situation.

The code in Timer1_Tick is roughly the same:

Private int_waitcount =0;Private voidTimer1_Tick (Objectsender, EventArgs e) {      //stop is generally not a disadvantage, and in some cases is necessary, such as the operation of the time required more than//timer1 interval (Interval), if no stop can occur unexpected results. timer1.      Stop (); if(Webbrowser1.document = =NULL|| WebBrowser1.Document.Body = =NULL|| WebBrowser1.Document.GetElementById ("Foo") ==NULL)      {           if(_waitcount >3) {MessageBox.Show ("There is a problem with the network, please try again sometime."); return; } _waitcount++; Timer1.           Start (); return;//continue to wait} _waitcount=0;//Recovery//the "foo" element detects that the AJAX request has returned the desired result and can proceed with the next step      ..............}

This uses a _waitcount global variable, the purpose is to avoid network problems, never load, causing the timer code is repeatedly triggered, into the dead loop. Try 4 times and if not, the prompt fails. This actually involves an important issue with browser Automation: error handling. Because the network situation is unpredictable, only programs that contain good error handling are more robust (robust). Many programs on the web, the surface looks like work, but encountered unexpected network conditions will be wrong, because the error is handled badly. This concrete is discussed again later.

If the previous if judging condition, if with the new framework of the grammar of the sugar, may also write simple, here does not change.

The main problem with the way the timer is felt in practice is that if there is too much Ajax in the web, it takes a lot of timer and the code seems a bit messy. Since the timer here is delayed, it should be available in other ways as well.

The simplest way to delay is thread.sleep (). The disadvantage is obvious, is blocking the main thread, causing false freezing phenomenon, the user experience is not good. So someone improved, you can refer to this link:

Https://stackoverflow.com/questions/3794522/waiting-for-webbrowser-ajax-content

It uses application.doevents () to avoid blocking. However, application.doevents () Use caution, refer to this link:

Https://stackoverflow.com/questions/5181777/use-of-application-doevents

My understanding is that if the time allowed for application.doevents () is too long, it is easy to give the user the opportunity to switch off the application, which can cause unexpected results. When dealing with Ajax requests, it is possible to wait a few seconds and a few seconds to appear somewhat longer. So Application.doevents () may be used here, not too good practice.

Another way to delay, although not limited to the application of browser automation, but since the talk, may wish to say. This is probably more in the game program, is similar to the following code:

var start = environment.tickcount;  while  - // Delay 100 ms {       application.doevents ();}

Blogging is time-consuming. Webbrower control There are a lot of questions to talk about and write later.

Some experience of browser Automation 2 WebBrowser control Ajax