Why is the Inet control so flaky????

[randem]

I use the Inet control on a form and it works EVERY TIME in the IDE but when it is run as an exe it gives errors such as 12029 cannot connect but in the IDE it works perfect. I stop using it for a while reboot a few times and it now wants to work from the exe...

What goes on with this control. I use the Inet1.OpenUrl function as well as the Inet1.Execute function all with using the InetUpdate_StateChanged event to process the data when icResponseCompleted is active.

Why is this control so flaky and how can one stabilize it?

[RhinoBull]

That's because IDE is slower then compiled version - you need to implement some sort of delay (perhaps like this):

    Do While Inet1.StillExecuting
        DoEvents
    Loop

[dilettante]

I don't even try anymore, and have stopped using it except for simple things like sync requests (via .OpenUrl) and not even then when I can avoid it.

For whatever reasons it has a number of problems. The most obvious I've found is that it won't signal all of the state transitions via the StateChanged event for FTP. This makes it useless for multistep operations (CD, DIR, PUT, CLOSE).

There isn't any reliable free substitute, though many of the for-pay ones do a good job. Some people go to using the WinInet API directly. I usually just automate a small FTP client that does StdIO streams (unlike the one that comes with Windows) via anonymous pipe redirection. For HTTP I go to the HTTPRequest object or the WinHTTPRequest object.

Using the WinHttpRequest COM Object

Of course I don't even try to support anything prior to XP SP2 anymore except in specific cases.

[randem]

Rhinobull,

Yes, I know that the IDE is slower and I do have code like you suggest but the events that fire are very different between the two. Sometime the proper events don't even fire. But in the IDE it does fire. That's the problem... It's hard to get something to work properly when you test something and then have it work completely different in the real world...

dilettante,

I might have to dump INET and move to something different...

[RhinoBull]

INet is a Win32 API wrapper so why not use original? Plenty of other ready-to-go samples can be found there as well.

[dilettante]

You never said whether you need this for HTTP/HTTPS or FTP. However I've already offered the few ideas I have for each.

I think that you're correct about timing and catching state changes. I'd have thought a StateChanged event message would be queued with the State value embedded in it, making it impossible to really lose a transition. I suspect these are sent as nonqueued messages, so if your program isn't sitting in the message loop they get lost.

Execute() can be really bad about this. The first one done after setting the destination URL and user/pw goes through multiple State transitions because it has to do things like authentication interaction with the server. Even the StateChanged events you get show that the process is treated as if you had explicitly made each request at each stage of session-setup.

In the IDE your may be slow enough that you only see the final State after an operation (or a few States). Running native-compiled you're faster, and so you see more State changes - even ones you didn't expect based on testing. I don't think you're ever fast enough to catch all of them though.