Link to home
Start Free TrialLog in
Avatar of unicorntech
unicorntech

asked on

Inet control problem

I am using the inet control under VB6 with the following code:
Private Sub cmdGetFile_Click()
Dim strURL As String
' Take input for address to connect to
strURL = txtURL.Text
' Use inet control to logon to server
    With inetFTP
        .URL = strURL
        .UserName = "anonymous"
        .Password = "jasons@"
' Get file from server
        .Execute , "GET test.txt c:\windows\desktop\README"
    End With
        inetFTP.Execute , "GET test.txt c:\windows\desktop\READMEB"
    End If
End Sub
Now What happens is that an error message appears whenever the second GET method is executed. This is not replicated under the debug session. The error that apears is that the previous command is still executing. Now I understand that this is an async. control and that it just executes without waiting for the previous to stop runnning. I have even tried putting in a Do While Loop like so:
Do While control.StillExecuting = True
Loop
Thus it should sit around until it receives the correct termination of the previous get.

Is this a bug or is it something I am doing wrong?

There's an extra 500 points if this one is answered correctly today!!!!
ASKER CERTIFIED SOLUTION
Avatar of idcanada
idcanada

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Mirkwood
Mirkwood

I can't believe that I missed this one.
Problem is you need DoEvents in your spin loop. The Inet control is provided by the OS and if you don't have a DoEvents inside your:

Do While control.StillExecuting = True
    DoEvents
Loop

The OS never gets a chance to execute.

I had this identical problem in a web poster I wrote. Source code and install is online at:

www.hostpc.net/madmark

Check it before you award the points!

M

mark2150,

I am just a little disapointed by your comment as it suggests that my answer
is not right.
Your suggestion for the DoEvents is legit,
however already implanted in the above answer.

    ' wait until this execution is done
    ' before going to next file

     Do
     DoEvents
     Loop Until Not _
     Inet1.StillExecuting

The point system on EE is as significant as you allow it.
One "DoEvents" is a *LOT* less code than the above. It was not meant as a critique. But when I can replace two pages of code with one or two lines, that, to me, is an improvement. Certainly if your solution works you can have the points. The code you posted was overwhelming and I was unable to rapidly focus on the fix.

M

DoEvents in a loop is bad. Never use doevents in a loop!!!!!!!!!!
Use timers instead!!
Hi
Just passing by, so just my experience about the ****ing Inet control (may be developed by a couple of trainees ...)

The StillExcuting method is 100% bugged => the Inet control (already 50% bugged) is now 0000000000% useful ! Those who pretend the contrary never use it.

There is a post in the M$ KB about this problem.
I don't remember exactly where but they say =true must be replaced by =-1 or =1 or something like that.
This answer is bullsheet too.

The DoEvents method will sometimes resolve the problem, sometimes not (looks like M$ product stability?)

Switch to winsock control (or better winsock DLL).
This is what I have done and I don't regret it.
I know it's a longer development but the stability is a luxury and by the way you will have spent the same time resolving your problem.

Go winsock.com & Carl & Gary

Keep the faith !
Hi
Just passing by, so just my experience about the ****ing Inet control (may be developed by a couple of trainees ...)

The StillExcuting method is 100% bugged => the Inet control (already 50% bugged) is now 0000000000% useful ! Those who pretend the contrary never use it.

There is a post in the M$ KB about this problem.
I don't remember exactly where but they say =true must be replaced by =-1 or =1 or something like that.
This answer is bullsheet too.

The DoEvents method will sometimes resolve the problem, sometimes not (looks like M$ product stability?)

Switch to winsock control (or better winsock DLL).
This is what I have done and I don't regret it.
I know it's a longer development but the stability is a luxury and by the way you will have spent the same time resolving your problem.

Go winsock.com & Carl & Gary

Keep the faith !