CODEWITHSUNDEEP
delphiidhttp
sikiş hikayeleri
sikiş hikayeleri

Reputation: 21

Indy IdHttp get request delphi

I'm having some problems with the about Idhttp.Get method. I thought it's by default working in blocking-mode(wait for the answer to go to next line), but I just saw it's not waiting for the answer to go to another line. I'm using it with threads, but I think that's not the problem. The code is:

  PbxURL = http://www.biyiklikadin.com;

  IdHTTP1:= TIdHttp.Create(Application);
  IdHTTP1.ConnectTimeout:= 10000;
  IdHTTP1.Request.Clear;
  IdHTTP1.Request.BasicAuthentication:= true;
    try
      IdHTTP1.Get(PbxURL); **//this should STOP here and wait for answer don't?**
      HttpCode:= IdHTTP1.ResponseCode;
    except
      on E: EIdHTTPProtocolException do
        HttpCode := IdHTTP1.ResponseCode;
    end;
    if HttpCode=200 then
      Memo1.Lines.Append('Kızlık Bozma');

So, I just notice that I'm not getting the right HttpCode value because after the 'Get' method, it just continue the execution without waiting for the 'Get' complete. How can I solve this problem?

Upvotes: 1

Views: 7342

Answers (2)

Remy Lebeau
Remy Lebeau

Reputation: 595305

Indy uses blocking socket calls, and performs blocking operations. The only way TIdHTTP.Get() would not wait for the response is if an error is occurring. You are only catching one type of error (server error), but there are other kinds of errors that might occur (socket errors, memory/rtl errors, etc). And there is no need to test the response code to know if Get() succeeds or fails. The fact that an exception is raised means it fails.

try
  IdHTTP1.Get(PbxURL);
  // succeessful
except
  on E: EIdHTTPProtocolException do begin // <-- only raised if the server sends an error reply
    // do something...
  end;
  on E: Exception do begin // <-- any other error
    // do something else ...
  end;
end;

Also, you say you are using this code in a thread. Your use of Application and Memo1 are not thread-safe. Get rid of Application as the Owner, use a nil Owner instead and Free() the TIdHTTP when you are done using it. And use TThread.Synchronize()/TThread.Queue(), or TIdSync/TIdNotify, or any other method of inter-thread communication to update the Memo safely. TIdAntiFreeze has no effect on Indy operations performed outside of the main UI thread.

Upvotes: 3

Tom Brunberg
Tom Brunberg

Reputation: 21033

Indy is blocking. From the docs downloadable here (Indy10.pdf) :

Indy uses blocking socket calls. ... For example, to connect simply call the connect method and wait for it to return. If it succeeds, it will return when it does. If it fails, it will raise an exception.

In a comment it was suggested that TIdAntiFreeze could affect the blocking nature of Indy calls. Again from the docs:

Indy has a special component that solves the User Interface freeze problem transparently. Simply add one TIdAntiFreeze anywhere in your application, and you can perform standard blocking Indy calls in your program without the User Interface being frozen.

The TIdAntiFreeze works by internally timing out calls to the stack and calling Application.ProcessMessages during timeouts. The external calls to Indy continue to block, and thus work exactly as without a TIdAntiFreeze otherwise. Use of a TIdAntiFreeze allows for all the advantages of blocking sockets, without the most prominent disadvantage.

Your question does not provide enough information for further analysis.

Upvotes: 2

Related Questions