it turned out the solution to the problem was very simple and i created a URL that does the required choice.
Yeah, that does a GET request, you explicitly said you needed a POST request.. and if you were sending to any server I wrote, and it was expecting a post and you sent it a get.. youd be shown to the digital door
WebBrowser1.DocumentCompleted event and it worked but i thought the code looked ugly.
Ugly works, but beautiful doesnt?
Ugly works because you have to wait for page 1 to load before jumping to page 2. this is because in the response of page 1, you get sent a cookie that keeps you logged in. No response=no cookie=no go.
The inclusion of My.Application.DoEvents() was i hoped a solution but not so.
People really, really, really need to get away from that naaasty old vb6 way of doing things. In vb6, we had doevents because it was single threaded, so any long running ops would mean that the thread that processes the window messages(mouse clicks, key presses) would be busy doing other things and the app would (look like it) "crashed"
Inserting a DoEvents every now and then in the longop meant that the thread would stop work, process all the queued up window messages and not look like it crashed.
Now that we have multi-threading, long ops are suppsoed to be done on a background thread so the windowing thread can still process its messages and not look like the app crashed.
Now that i've given youa brief history of DoEvents, you can hopefully see how:
a) it has nothing to do with your app "doing all the work you told it to do like navigating a web browser"
b) it is only purely to do with the window messages sent to it by the user mouse, and keyboard (and windows dummy messages to see if it is "Not Responding")
c) given that its something of a no-no and hence almost like a swear word in your code, it might just be uglier than the other route!
Does anyone have any suggestions on how this code would work as intended?
the "ugly" way...