I downloaded the trial of the HTTP component(VB6 ActiveX.) I noticed if I use back to back requests, specifically PostUrlEncoded, in my case, that the interface locks up momentarily at the back end of the requests. The length of time varies, but it's definitely noticeable and a problem for me.
I use two timers within my connection object I created to simulate a timeout and a checking loop. I'm thinking it is locking up when I call BgTaskAbort.
Here is my current code for said timers:
Private Sub tmrCheck_Timer()
If http.BgTaskFinished = False Then Exit Sub End If RequestCompleted = True ' Request has been completed. tmrCheck.Enabled = False Set response = http.BgResponseObject If (response Is Nothing) Then RaiseEvent Error("NO_DATA") Exit Sub End If RaiseEvent DataReceived(response.bodyStr)
Private Sub tmrTimeout_Timer()
tmrTimeout.Enabled = False tmrCheck.Enabled = False If RequestCompleted = False Then Debug.Print "Connection timed out." http.BgTaskAbort RaiseEvent Timeout End If
When the Timeout event is raised, the program makes another connection immediately. It traverses through a list of given links.
I was connecting to my server that requires HTTPS, so my requests where POST requests to https://mydomain.com/input.ext.
Am I not stopping things correctly, or what? I put a delay between the connections(3 to 5 seconds), even, and that did not stop the problem.
Your product would be an ideal solution for me, but as it is, I cannot use it unless I can resolve this issue. The interface of the program is important, and I cannot have it being blocked -- even momentarily.
I reviewed the internal code for BgTaskAbort, and I think it's very unlikely that the method is causing a delay -- meaning that the method call takes a significant amount of time before it returns control to your application code. The reason is that the BgTaskAbort, internally, simply sets an internal flag variable and returns. (The background thread will notice that the "abort" flag was set and it will then abort whatever operation is in progress.)
The best approach is to identify which Chilkat method call is not returning quickly, and then examine the contents of the LastErrorText after the method call.
Hi, I believe you are correct. It appears to hang on PostUrlEncoded
Here is my code:
Public Function Connect(Optional httpURL As String = "") http.KeepEventLog = True http.VerboseLogging = True http.DebugLogFilePath = "C:\childebug.txt" Debug.Print "CONNECT" Dim sp() As String RequestCompleted = False If httpURL = "" Then httpURL = URL tmrTimeout.Interval = Timeout tmrTimeout.Enabled = True If Proxy <> "" Then sp = Split(Proxy, ":") http.ProxyDomain = sp(0) http.ProxyPort = CLng(sp(1)) End If Debug.Print "CONNECT 1" If rqType = rqPOST Then ' Parse request variables... setPostVariables http.FollowRedirects = False Debug.Print "CONNECT 2" http.PostUrlEncoded httpURL, request Debug.Print http.LastErrorText Debug.Print "CONNECT 3" tmrCheck.Enabled = True End If
When the program freezes, I see in the Immediate window that "CONNECT" is printed, but not "CONNECT 1." I'm unsure if this is because of a previous connection.
I enabled verbose logging, and in the log file, there is no helpful information. This block is repeated throughout the file, without any change(Also in the Immediate window where I print it):
PostUrlEncoded: DllDate: Aug 5 2012 UnlockPrefix: Anything for 30-day trial Username: Box:User Architecture: Little Endian; 32-bit Language: ActiveX VerboseLogging: 1 Task started in background thread. (leaveContext) VerboseLogging: 1
Other than this hanging, I really do like the simplicity of your product. It will expedite my web related projects greatly.
NOTE: I was using an https address. Thinking it may be the secure handshake or encryption, I switched to standard http, and no change.
Here's a new build that will log (in LastErrorText) the number of milliseconds it takes to start the background thread that will do the PostUrlEncoded:
I reviewed the internal code, and starting the background thread is the only thing that could possibly take any amount of time. If the problematic time delay is truly in this method, then I don't see a "fix" because there's nothing that can be changed -- it's simply a call to the MS Platform SDK "CreateThread" function. (http://msdn.microsoft.com/en-us/library/windows/desktop/ms682453%28v=vs.85%29.aspx)