Using the Internet Transfer Control: Part 2

Tuesday Nov 19th 2002 by Sam Huggill

Using the Internet Transfer Control: Part 2

In the second part of this series, we take a look at the different states the Inet control can be in, and how we can trap errors.

The Internet Transfer Control provides us with one event, StateChanged. And, when this event is raised, it provides only one parameters, State. We can use this parameter to detect what state the control is in, and then react accordingly.

In the first part of this article, we take you through the basics of creating an ActiveX control in Visual Basic. We will explain the basics behind controls and how you can use some cool techniques to create a decent control.

The best way to get to know the Inet controls constants is to look at it using the Object Browser. To do this, load up VB and add the Inet control to a form (Project, Components, Microsoft Internet Transfer Control). Now Click View, Object Browser (or press F2). From the combo box select InetCtlsObjects. You can now look through the different constants; Access constants, Data Type constants, Error constants, Protocol constants and State constants. 

To start with, we are mainly interested in the State constants. To see what each constant means, I have described them below (the number in brackets is the constants actual value):

  • icConnected (4) - Connected
  • icConnecting (3) - Connecting
  • icDisconnected (10) - Disconnected
  • icDisconnecting (9) - Disconnecting
  • icError (11) - An error has occurred
  • icHostResolved (2) - The remote address given has been accepted
  • icNone (0) - No current state
  • icReceivingResponse (7) - A response is current being received
  • icRequesting (5) - Data is currently being requested
  • icRequestSent (6) - A data request has been sent
  • icResolvingHost (1) - The remote address given is currently being checked
  • icResponseCompleted (12) - A response was successfully completed
  • icResponseReceived (8) - A response has been received

OK. I won't go through and describe them all, but I will point out some of the more useful ones. First of all, icConnected provides you with a failsafe way of knowing that you are connected to a remote machine. As icDisconnected also provides you with a way of knowing when you are offline. Probably the most useful constant is icError. This tells us that an error has occurred. We can now check using the ErrorConstants for the actual error that has occurred.

When looking at the ErrorConstants, there are quite a lot. Well, don't worry, we don't need all of them. I have outlined the important ones below:

  • icBadUrl
  • icCannotConnect
  • icConnectFailed
  • icConnectionAborted
  • icNoRemoteHost

Most of them are self explanatory, although I do want to point out one thing. The difference between icConnectFailed and icConnectionAborted is that icConnectionAborted shows that we were previously connected, but the remote host disconnected us.

Well, now that we have all these nice constants, how can we use them to detect and find out what's gone wrong?

You might have guessed that we need to work in the StateChanged event. We need to use the Select Case statement to detect the State, because it's a real pain to use lots of If statements:

Select Case State

  Case icError

    ' An error has occurred

End Select

A good way to find out what's going on is to use the Debug.Print method in the StateChanged event. For example, when using the code in the first part of the series to get a web page, you would see the following displayed in the Immediate window:


Uh?? What's all this? Am I supposed to memorize these numbers? No. The constants listed earlier with the numbers in brackets refer to these numbers. Here is what the numbers above translate to:

  • 1 - icResolvingHost
  • 7 - icReceivingResponse
  • 8 - icResponseReceived
  • 9 - icDisconnecting
  • 10 - icDisconnected

As we can see the Inet control works fairly logically, first resolving the host name from the URL given, then getting a response and then disconnecting. If we provide an incorrect url, as in "http://" then we need to use standard error handling to pick up the error:

Private Function GetPage(strURL As String) As String

On Error Goto vbErrHand

' Code here

Exit Function


Msgbox Err.Description

End Function

Unfortunately there is no way to detect runtime errors, as the error numbers provided by the Err object do not match with the Inet controls error constants. For example, if you provide a url of "http://" with no error handling, then a runtime error occurs with the description of "URL is malformed." Now, the error constant icBadUrl is also described as URL is malformed, but the numbers just don't match. So, instead, we just have to tell the user.

When it comes to detecting connection errors etc, we are going to have more problems. The Inet control provides us with two properties for getting response information, these are:

  • ResponseCode
  • ResponseInfo

Now, ResponseInfo usually gives a string very similar to the name of the corresponding ic constant. But, the ResponseCode is different! What a pain. But, there is a small workaround. You can create a standard module that contains some string constants that contain the responses returned. Here is a sample constant:

Public Const UNRESOLVED As String = _
             "Name not resolved"

You can use this as follows:

Private Sub Inet1_StateChanged(ByVal State As Integer)

Select Case State

  Case icError
    SelectError Inet1.ResponseInfo

End Select

End Sub

Private Sub SelectError(errStr As String)

Select Case errStr

    Msgbox "The host name given could not be resolved."

End Select

End Sub

That's about it for this time, but in the next part I will take you through connecting to an FTP Server using the Inet control.

I have made a small demo project to accompany this article. It works to display errors that occur when using the Inet control.

Download the files

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved