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()
Private Sub tmrTimeout_Timer()
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.
asked Nov 26 '12 at 07:20
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.
answered Nov 26 '12 at 17:02
Hi, I believe you are correct. It appears to hang on PostUrlEncoded
Here is my code:
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):
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.
answered Nov 26 '12 at 18:34
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)
answered Nov 26 '12 at 19:02