Max Kielland
Max Kielland

Reputation: 5841

Indy IdHTTP not reporting status correctly

I have assigned the OnStatus handler to update a label with the AStatusText parameter.

When setting a breakpoint in the handler it only breaks on the hsConnected status when I do a Get("google.com"). I know that I shouldn't get the full range but I should at least get the hsResolving and hsConnecting messages before the hsConnected.

List of available statuses:

hsResolving,
hsConnecting,
hsConnected,
hsDisconnecting,
hsDisconnected,
hsStatusText,
ftpTransfer,
ftpReady,
ftpAborted

Any idea of why I don't get the other statuses?

Upvotes: 1

Views: 617

Answers (1)

Remy Lebeau
Remy Lebeau

Reputation: 597941

hsConnected is reported by the OnStatus event of TIdTCPClientCustom, but the other statuses you are looking for are reported by the OnStatus event of TIdIOHandler instead.

If TIdTCPClientCustom.Connect() or TIdCustomHTTP.CheckAndConnect() has to create a new implicit IOHandler object, an OnStatus handler gets assigned to it so the TIdTCPClientCustom.OnStatus event is called. However, if an IOHandler is already assigned before Connect() is called, no OnStatus handler gets assigned. You would have to assign your own OnStatus handler to whatever IOHandler you assign.

There is a TODO item to make the OnStatus event hookup more automated.

The most likely scenario for this happening is if you are manually assigning your own SSLIOHandler before requesting HTTPS urls. In that case, you can assign an OnStatus handler to your SSLIOHandler. On the other hand, if you are using an up-to-date version of Indy, it is able to create an implicit SSLIOHandler automatically (which includes OnStatus hookup) so you do not have to assign your own anymore (unless you need to customize its settings):

New HTTPS functionality for TIdHTTP

TIdHTTP now has new functionality that allows it to auto-create an internal default SSLIOHandler object when requesting an HTTPS url if no IOHandler has been assigned yet.

Upvotes: 1

Related Questions