[VB.net] Webform invullen i.c.m. mshtml.dll vertraagd

[Kachelpijp]

Ik ben bezig met het maken van een programma dat mijn rooster ophaalt van het internet. Om bij mijn rooster te komen moeten er eerst een paar velden worden ingevuld. Ik maak gebruik van SHDocVw.dll en mshtml.dll om velden in te vullen op een website en dat gaat prima, totdat ik op submit wil drukken met de volgende code:

Visual Basic .NET:

            'variabelen aan het begin van het programma
            Dim HTMLDoc2 As mshtml.HTMLDocument
            HTMLDoc2 = wbBrowser.Document

            Dim iHTMLCol2 As IHTMLElementCollection
            Dim iHTMLEle2 As IHTMLElement
            Dim str2 As String
            iHTMLCol2 = HTMLDoc.getElementsByTagName("input")           

            'submit button
            For Each iHTMLEle2 In iHTMLCol2
                If Not iHTMLEle2.getAttribute("name") Is Nothing Then
                    str2 = iHTMLEle2.getAttribute("name").ToString
                    If str2 = "roosterknop" Then
                        iHTMLEle2.click()                     'iHTMLEle2.setAttribute("value", waarde) voor invullen van veld
                        Exit For
                    End If
                End If
            Next

Het invullen van het veld zelf gebeurt met dezelfde code, maar met iHTMLEle2.setAttribute.
Tussen de invul en submit activiteiten door zit een lus die wacht totdat de browser niet meer bezig is en de nieuwe instructies dus kunnen beginnen:

Visual Basic .NET:

Do
Loop Until Not wbBrowser.Busy

De velden worden keurig ingevuld zodra de pagina geladen is, maar het moment waarop de submit button wordt ingedrukt verschilt sterk. Soms direct na het invullen van het formulier, maar soms kan het wel een minuut duren.
Ik heb al geprobeerd om de delay lus eruit te gooien, maar dan komen de instructies niet bij de browser aan omdat die nog bezig is met andere dingen/laden.

Dus de vraag luid: Hoe zorg ik ervoor dat de submit button direct na het invullen van het veld wordt ingedrukt zonder vertraging?

[RobIII]

Sowieso is een "busy loop" als deze gewoon een slecht idee; zet er dan een sleep(1) in ofzo (of een DoEvents).

Maar waarom doe je uberhaupt zo moeilijk met msmhtml en SHDocVw etc. Je weet dat je ook gewoon zonder die zaken gegevens kunt POST-en? Ik weet 't even niet uit mijn blote bol, maar je moet een WebClient of WebRequest/WebResponse gebruiken. Even MSDN in duiken en dan vindt je het vast

[Kachelpijp]

En dat was de oplossing: heet loopje ook nog wat laten doen i.p.v. niks
Voor het complete plaatje:

Visual Basic .NET:

Do
     System.Threading.Thread.Sleep(1)
Loop Until Not wbBrowser.Busy

Ik heb er bewust voor gekozen om het via de browser te doen en niet met httpRequests, want de site maakt ook gebruik van cookies en een soort van tijds-afhankelijke validatie, en dat werd nogal lastig om na te bootsen, du vandaar

[Janoz]

Kachelpijp schreef op zondag 13 september 2009 @ 19:13:
En dat was de oplossing: heet loopje ook nog wat laten doen i.p.v. niks

Sorry, het is precies omgekeerd. Je oude code was vooral heel erg veel aan het doen terwijl juist je nieuwe code vooral zit te niksen. Het heet niet voor niks een busy wait loopje.

Daarnaast neem ik aan dat het webclient object een beetje te vergelijken is met de httpclient van Jakarta voor java. Daar wordt al het cookie geneuzel gewoon keurig voor je afgehandeld. Dat zou dus het probleem helemaal niet hoeven zijn.

[Kachelpijp]

Zo kan je het ook zien ja
Maar de httpRequest, httpWebRequest en webRequest zijn allemaal low-level, omdat ze er bij vb.net vanuit gaan dat je een browser als user-control gebruikt, dus je moet de hele request zelf maken d.m.v. webrequest.setattribute. En dan moet je nog de JavaScript en tijdsvalidatie over de geposte data leggen en de cookies overhelven. En om het nog leuker te maken: er zitten in de stap van invullen naar het rooster nog een paar redirects die ook weer met de cookies rommelen en een lichte validatie doen, dus al met al is het simpeler om het via de browser te doen.

Maarja... het werkt en we zijn weer wat wijzer, dus eind goed al goed