Microsoft & .NET Visual Basic Using the Internet Transfer Control: Part 2

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:

1
7
8
9
10

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

vbErrHand:

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

  Case UNRESOLVED
    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

Latest Posts

Related Stories