WebSocket Delphi ActiveX Reference Documentation

TChilkatWebSocket

Current Version: 11.5.0

Chilkat.WebSocket

Connect to WebSocket servers and exchange client-side frames and messages.

Client-side only: Chilkat.WebSocket implements the client side of the WebSocket protocol. It initiates an opening handshake with an existing WebSocket server. It does not listen for incoming connections, accept clients, or implement a WebSocket server.

Chilkat.WebSocket operates over an established Chilkat.Rest connection. It creates and validates the HTTP upgrade handshake, sends and receives text or binary frames, supports fragmented messages, handles Ping, Pong, and Close control frames, polls for incoming data, and exposes frame-level diagnostics.

Client opening handshake

Upgrade a connected Rest session to WebSocket and validate the server's response before exchanging frames.

Text and binary messages

Send UTF-8 text or exact binary bytes as single-frame or fragmented WebSocket messages.

Frame-by-frame receiving

Read frames, inspect opcodes and the FIN state, and accumulate fragments until a complete message is available.

Ping and Pong

Use automatic or manual control-frame handling for keep-alive and responsiveness checks.

Clean close handshake

Exchange Close frames, inspect the peer's status code and reason, and terminate the underlying connection cleanly.

Separate read/write paths

Share a connection between two WebSocket objects when one thread needs to read while another writes.

Typical connection sequence: Connect a Rest object to the server, call UseConnection, call AddClientHeaders, send the opening HTTP GET request through Rest, and then call ValidateServerHandshake. Only after validation succeeds should the application call frame send/receive methods.
Frames versus messages: A WebSocket message may consist of one frame or several fragments. When receiving a fragmented message, call ReadFrame until FinalFrame is 1, then retrieve the accumulated data with GetFrameData, GetFrameDataSb, or GetFrameDataBd.

Object Creation

var
obj: TChilkatWebSocket;
...
begin
obj := TChilkatWebSocket.Create(Self);
...
// When finished, free the object instance.
obj.Free();

Properties

CloseAutoRespond
property CloseAutoRespond: Integer
Introduced in version 9.5.0.70

Controls whether Chilkat automatically answers an incoming Close control frame.

  • When 1, an incoming Close is answered automatically if the client did not already initiate the close. After a Close has been both received and sent, Chilkat closes the underlying connection.
  • When 0, the application can detect the received Close through CloseReceived or FrameOpcode and call SendClose itself.

The default is 1.

Closing handshake: A peer that receives a Close and has not already sent one should respond with a Close. Automatic response is usually the safest choice unless the application must control the exact status code or timing.

top
CloseReason
property CloseReason: WideString readonly
Introduced in version 9.5.0.70

Returns the UTF-8 reason text contained in the received Close control frame.

The value is empty when the peer supplied no reason or when no Close frame has been received. A reason is diagnostic text and should not be treated as a stable machine-readable error identifier; use CloseStatusCode for protocol-level handling.

top
CloseReceived
property CloseReceived: Integer readonly
Introduced in version 9.5.0.70

1 after a Close control frame has been received on the current WebSocket connection.

When CloseAutoRespond is 0, use this property to determine whether the application needs to call SendClose to complete the closing handshake. The received status code and reason, if present, are available through CloseStatusCode and CloseReason.

top
CloseStatusCode
property CloseStatusCode: Integer readonly
Introduced in version 9.5.0.70

Returns the status code contained in the received Close control frame.

Returns 0 when no Close frame has been received or when the received Close frame did not include a status code.

Meaning of zero: 0 is an API sentinel; it is not a WebSocket close status transmitted by the peer.

top
DebugLogFilePath
property DebugLogFilePath: WideString

If set to a file path, this property logs the LastErrorText of each Chilkat method or property call to the specified file. This logging helps identify the context and history of Chilkat calls leading up to any crash or hang, aiding in debugging.

Enabling the VerboseLogging property provides more detailed information. This property is mainly used for debugging rare instances where a Chilkat method call causes a hang or crash, which should generally not happen.

Possible causes of hangs include:

  • A timeout property set to 0, indicating an infinite timeout.
  • A hang occurring within an event callback in the application code.
  • An internal bug in the Chilkat code causing the hang.

More Information and Examples
top
FinalFrame
property FinalFrame: Integer readonly
Introduced in version 9.5.0.70

1 if the frame most recently delivered by ReadFrame had its WebSocket FIN bit set; otherwise 0.

For a fragmented data message, continue reading while this property is 0. The fragment with 1 completes the message. Unfragmented messages have 1 on their only frame.

Control frames: Close, Ping, and Pong are control frames and are not fragmented by the WebSocket protocol; their FIN bit is always set.

top
FrameDataLen
property FrameDataLen: Integer readonly
Introduced in version 9.5.0.70

Returns the number of payload bytes currently accumulated in the internal receive buffer.

The value can represent data from one frame or from multiple calls to ReadFrame, which is useful when receiving a fragmented message. The accumulated bytes remain available until retrieved by GetFrameData, GetFrameDataSb, or GetFrameDataBd.

Message length: This is the length accumulated so far, not necessarily the final length of the complete WebSocket message. Check FinalFrame to determine whether the last received fragment completed the message.

top
FrameOpcode
property FrameOpcode: WideString readonly
Introduced in version 9.5.0.70

Returns the symbolic opcode of the frame most recently delivered by ReadFrame.

ValueMeaning
ContinuationA later fragment of a Text or Binary message
TextUTF-8 text data
BinaryBinary data
CloseClosing handshake
PingPing control frame
PongPong control frame

Before any frame has been received, the value is the empty string. Ping or Pong frames handled internally by the auto-response/auto-consume options may not be returned as the current frame.

top
FrameOpcodeInt
property FrameOpcodeInt: Integer readonly
Introduced in version 9.5.0.70

Returns the numeric opcode of the frame most recently delivered by ReadFrame.

ValueFrame type
0Continuation
1Text
2Binary
8Close
9Ping
10Pong

Use FrameOpcode when a readable symbolic value is preferred.

top
HeartbeatMs
property HeartbeatMs: Integer
Introduced in version 9.5.0.97

Specifies the interval, in milliseconds, between AbortCheck event callbacks during supported blocking operations.

The default is 0, which disables periodic AbortCheck callbacks. Set a positive value when the application needs an opportunity to cancel a long-running send or receive operation.

Not a WebSocket heartbeat: Despite the property name, this setting does not transmit Ping frames and does not monitor peer liveness. Use SendPing and Ping/Pong handling for protocol-level heartbeat behavior.

More Information and Examples
top
IdleTimeoutMs
property IdleTimeoutMs: Integer

Specifies the maximum number of milliseconds an active send or receive operation may remain stalled while waiting for additional network progress.

The default is 30000 milliseconds (30 seconds). This is an inactivity timeout, not a total limit on the duration of the operation. An operation may continue longer than this value as long as data continues to be transferred.

Not a keep-alive interval: This property does not automatically send WebSocket Ping frames. Use SendPing when the application needs protocol-level keep-alive or responsiveness checks.

top
IsConnected
property IsConnected: Integer readonly
Introduced in version 9.5.0.70

1 when the underlying WebSocket network connection is currently open; otherwise 0.

Connection state is not a health check: A network interruption may not be detected until the next read or write operation. Use normal I/O results—and optionally Ping/Pong—to determine whether a seemingly connected peer is still responsive.

top
LastBinaryResult
property LastBinaryResult: OleVariant readonly

This property is mainly used in SQL Server stored procedures to retrieve binary data from the last method call that returned binary data. It is only accessible if Chilkat.Global.KeepBinaryResult is set to 1. This feature allows for the retrieval of large varbinary results in an SQL Server environment, which has restrictions on returning large data via method calls, though temp tables can handle binary properties.

top
LastErrorHtml
property LastErrorHtml: WideString readonly

Provides HTML-formatted information about the last called method or property. If a method call fails or behaves unexpectedly, check this property for details. Note that information is available regardless of the method call's success.

top
LastErrorText
property LastErrorText: WideString readonly

Provides plain text information about the last called method or property. If a method call fails or behaves unexpectedly, check this property for details. Note that information is available regardless of the method call's success.

top
LastErrorXml
property LastErrorXml: WideString readonly

Provides XML-formatted information about the last called method or property. If a method call fails or behaves unexpectedly, check this property for details. Note that information is available regardless of the method call's success.

top
LastMethodSuccess
property LastMethodSuccess: Integer

Indicates the success or failure of the most recent method call: 1 means success, 0 means failure. This property remains unchanged by property setters or getters. This method is present to address challenges in checking for null or Nothing returns in certain programming languages. Note: This property does not apply to methods that return integer values or to boolean-returning methods where the boolean does not indicate success or failure.

top
LastStringResult
property LastStringResult: WideString readonly

In SQL Server stored procedures, this property holds the string return value of the most recent method call that returns a string. It is accessible only when Chilkat.Global.KeepStringResult is set to TRUE. SQL Server has limitations on string lengths returned from methods and properties, but temp tables can be used to access large strings.

top
LastStringResultLen
property LastStringResultLen: Integer readonly

The length, in characters, of the string contained in the LastStringResult property.

top
NeedSendPong
property NeedSendPong: Integer readonly
Introduced in version 9.5.0.70

1 when a Ping frame has been received but no corresponding Pong has yet been sent.

This property is primarily useful when PingAutoRespond is 0. Call SendPong as soon as practical; it automatically sends the received Ping payload in the Pong response.

top
PingAutoRespond
property PingAutoRespond: Integer
Introduced in version 9.5.0.70

Controls automatic handling of incoming Ping control frames.

  • When 1, Chilkat sends the required Pong automatically and ReadFrame consumes the Ping internally, continuing until another frame is available.
  • When 0, the Ping can be returned to the application. Check NeedSendPong and call SendPong as soon as practical.

The default is 1.

Payload echo: A Pong sent in response to a Ping must carry the same application data. SendPong automatically uses the stored payload of the unanswered Ping.

top
PongAutoConsume
property PongAutoConsume: Integer
Introduced in version 9.5.0.70

Controls whether incoming Pong control frames are hidden from the application.

  • When 1, ReadFrame consumes Pong frames internally and continues reading until a non-Pong frame is available.
  • When 0, an incoming Pong can be returned normally with FrameOpcode equal to Pong.

The default is 1. Check PongConsumed after ReadFrame to learn whether one or more Pong frames were consumed during that call.

top
PongConsumed
property PongConsumed: Integer readonly
Introduced in version 9.5.0.70

1 if the most recent call to ReadFrame internally consumed a Pong frame while PongAutoConsume was 1.

The property is reset to 0 at the beginning of each ReadFrame call and set to 1 if a Pong is consumed during that call.

Why unsolicited Pong is possible: Either endpoint may send a Pong without a preceding Ping, and a response to an earlier Ping may arrive between application data frames. Automatic consumption allows ordinary read loops to ignore these control frames while still detecting that they occurred.

top
ReadFrameFailReason
property ReadFrameFailReason: Integer readonly
Introduced in version 9.5.0.70

When ReadFrame returns 0, this property categorizes the reason:

ValueMeaning
0No failure is recorded
1Read inactivity timeout
2Aborted by an application callback
3Fatal socket error or lost connection
4Invalid WebSocket frame bytes were received
99Unexpected catch-all failure

Use this value for programmatic branching and inspect LastErrorText for detailed diagnostics.

top
UncommonOptions
property UncommonOptions: WideString readonly
Introduced in version 9.5.0.80

Contains a comma-separated list of rarely needed compatibility or platform options. The default is the empty string and should normally remain unchanged.

KeywordEffect
ProtectFromVpnOn Android, attempts to route the connection outside an installed or active VPN. Introduced in v9.5.0.80.
Platform-specific behavior: This option applies only on Android. Leave the property empty on other platforms and unless bypassing the device VPN is an explicit application requirement.

top
VerboseLogging
property VerboseLogging: Integer

If set to 1, then the contents of LastErrorText (or LastErrorXml, or LastErrorHtml) may contain more verbose information. The default value is 0. Verbose logging should only be used for debugging. The potentially large quantity of logged information may adversely affect peformance.

top
Version
property Version: WideString readonly

Version of the component/library, such as "10.1.0"

More Information and Examples
top

Methods

AddClientHeaders
function AddClientHeaders(): Integer;
Introduced in version 9.5.0.70

Adds the standard client opening-handshake headers to the Rest object supplied to UseConnection:

Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: ...
Sec-WebSocket-Version: 13

Sec-WebSocket-Key contains a newly generated client nonce used by the server to produce Sec-WebSocket-Accept.

Additional handshake headers: If the server requires headers such as Origin, Authorization, cookies, or Sec-WebSocket-Protocol, add them through the associated Rest object before sending the HTTP upgrade request.

Returns 1 for success, 0 for failure.

More Information and Examples
top
CloseConnection
function CloseConnection(): Integer;
Introduced in version 9.5.0.70

Immediately closes the underlying network connection without completing the WebSocket closing handshake.

Use this method when the connection must be abandoned because of a fatal error, timeout, application shutdown, or an unresponsive peer.

Preferred shutdown: For a normal shutdown, call SendClose, receive the peer's Close frame with ReadFrame, and allow the closing handshake to complete. An abrupt transport close does not provide the peer with a WebSocket status code or reason.

Returns 1 for success, 0 for failure.

top
GetFrameData
function GetFrameData(): WideString;
Introduced in version 9.5.0.70

Returns the bytes accumulated by successful calls to ReadFrame as a string, then clears the internal receive buffer.

This method is intended for WebSocket text-message data. For arbitrary binary payloads, use GetFrameDataBd to avoid interpreting binary bytes as text.

Fragmented messages: To retrieve an entire fragmented message, continue calling ReadFrame until FinalFrame is 1, and then call GetFrameData once. Calling this method earlier returns and clears only the data accumulated so far.

Returns a zero-length WideString on failure

top
GetFrameDataBd
function GetFrameDataBd(binData: IChilkatBinData): Integer;
Introduced in version 9.5.0.70

Appends the bytes accumulated by successful calls to ReadFrame to binData, then clears the internal receive buffer.

Use this method for binary messages or whenever the exact received bytes must be preserved. Existing data in the destination BinData is retained because the received bytes are appended.

Receive-buffer ownership: Calling any one of GetFrameData, GetFrameDataSb, or GetFrameDataBd consumes the same internal buffer. Retrieve the data using only the form needed by the application.
More Information and Examples
top
GetFrameDataSb
function GetFrameDataSb(sb: IChilkatStringBuilder): Integer;
Introduced in version 9.5.0.70

Appends the text represented by the bytes accumulated by successful calls to ReadFrame to sb, then clears the internal receive buffer.

Existing text in the destination StringBuilder is retained. This method is most appropriate for text-message data; use GetFrameDataBd for arbitrary binary payloads.

Fragmented messages: The receive buffer can accumulate multiple frames. Read until FinalFrame is 1 before calling this method when the application wants the complete message.
top
LoadTaskCaller
function LoadTaskCaller(task: IChilkatTask): Integer;
Introduced in version 9.5.0.80

Loads the caller object associated with an asynchronous Task method invocation.

This is used by Chilkat's asynchronous task infrastructure when access to the original WebSocket object is required after the task completes.

Returns 1 for success, 0 for failure.

top
PollDataAvailable
function PollDataAvailable(): Integer;
Introduced in version 9.5.0.70

Checks whether bytes are currently waiting to be read from the underlying WebSocket connection.

Returns 1 when incoming data is available and 0 when no data is presently waiting.

Polling is only a snapshot: A 1 result does not mean that an entire WebSocket frame or message has arrived. Call ReadFrame to parse the protocol frame. A 0 result does not indicate that the peer will not send data later.
top
ReadFrame
function ReadFrame(): Integer;
Introduced in version 9.5.0.70

Reads the next WebSocket frame from the connected server. On success, the method updates FrameOpcode, FrameOpcodeInt, FinalFrame, and FrameDataLen.

Frame payload bytes are added to an internal receive buffer. The buffer may therefore contain data accumulated by multiple calls to ReadFrame. Retrieve and clear it with GetFrameData, GetFrameDataSb, or GetFrameDataBd.

Reading a complete message

Call ReadFrame until FinalFrame is 1, then retrieve the accumulated message data. A fragmented message begins with a Text or Binary frame and continues with one or more Continuation frames.

Control-frame automation: Depending on PingAutoRespond and PongAutoConsume, incoming Ping and Pong frames may be handled internally, causing this method to continue reading until another frame is available. If the method returns 0, inspect ReadFrameFailReason and LastErrorText.

Returns 1 for success, 0 for failure.

top
ReadFrameAsync (1)
function ReadFrameAsync(): IChilkatTask;
Introduced in version 9.5.0.70

Creates an asynchronous task to call the ReadFrame method with the arguments provided.

Note: Async method event callbacks happen in the background thread. Accessing and updating UI elements existing in the main thread may require special considerations.

Returns nil on failure

top
SendClose
function SendClose(includeStatus: Integer; statusCode: Integer; reason: WideString): Integer;
Introduced in version 9.5.0.70

Sends a WebSocket Close control frame and begins or completes the closing handshake.

  • If includeStatus is 0, the Close frame contains no status code and statusCode and reason are ignored.
  • If includeStatus is 1, the frame contains statusCode followed by the UTF-8 bytes of reason.

The complete Close payload cannot exceed 125 bytes, leaving at most 123 bytes for the UTF-8 reason after the two-byte status code. Chilkat truncates an overlong reason. The API accepts status-code integers from 0 through 16383.

Protocol-valid status codes: The API's numeric range is broader than the set valid for transmission under RFC 6455. Use a defined protocol code such as 1000 for normal closure, or an appropriate application code in the 30004999 range. Codes 1005, 1006, and 1015 are reserved reporting values and must not be sent in a Close frame.
Clean close: After initiating a close, read the peer's Close response. If this method answers a Close already received from the server, Chilkat also closes the underlying connection after sending the response.

Returns 1 for success, 0 for failure.

top
SendCloseAsync (1)
function SendCloseAsync(includeStatus: Integer; statusCode: Integer; reason: WideString): IChilkatTask;
Introduced in version 9.5.0.70

Creates an asynchronous task to call the SendClose method with the arguments provided.

Note: Async method event callbacks happen in the background thread. Accessing and updating UI elements existing in the main thread may require special considerations.

Returns nil on failure

top
SendFrame
function SendFrame(stringToSend: WideString; finalFrame: Integer): Integer;
Introduced in version 9.5.0.70

Sends one WebSocket text data frame containing stringToSend. WebSocket text data is UTF-8 on the wire.

  • Set finalFrame to 1 when this frame completes the message.
  • Set finalFrame to 0 when additional frames will follow as part of the same fragmented message.

For a normal unfragmented text message, call this method once with finalFrame set to 1. For a fragmented message, call it repeatedly and set 1 only for the final fragment.

Frames and messages: A WebSocket message may contain one frame or multiple fragments. Do not begin a second data message until the current fragmented message has been completed. Control frames such as Ping, Pong, and Close may occur between message fragments.

Returns 1 for success, 0 for failure.

top
SendFrameAsync (1)
function SendFrameAsync(stringToSend: WideString; finalFrame: Integer): IChilkatTask;
Introduced in version 9.5.0.70

Creates an asynchronous task to call the SendFrame method with the arguments provided.

Note: Async method event callbacks happen in the background thread. Accessing and updating UI elements existing in the main thread may require special considerations.

Returns nil on failure

top
SendFrameBd
function SendFrameBd(bdToSend: IChilkatBinData; finalFrame: Integer): Integer;
Introduced in version 9.5.0.70

Sends one WebSocket binary data frame containing the current bytes in bdToSend.

  • Set finalFrame to 1 when this frame completes the binary message.
  • Set finalFrame to 0 when additional binary-message fragments will follow.

For an ordinary single-frame binary message, set finalFrame to 1.

Exact bytes: No text encoding is involved. The bytes stored in bdToSend become the frame payload, while Chilkat applies the client-side WebSocket framing and masking required by the protocol.

Returns 1 for success, 0 for failure.

More Information and Examples
top
SendFrameBdAsync (1)
function SendFrameBdAsync(bdToSend: IChilkatBinData; finalFrame: Integer): IChilkatTask;
Introduced in version 9.5.0.70

Creates an asynchronous task to call the SendFrameBd method with the arguments provided.

Note: Async method event callbacks happen in the background thread. Accessing and updating UI elements existing in the main thread may require special considerations.

Returns nil on failure

top
SendFrameSb
function SendFrameSb(sbToSend: IChilkatStringBuilder; finalFrame: Integer): Integer;
Introduced in version 9.5.0.70

Sends one WebSocket text data frame containing the current contents of sbToSend.

  • Set finalFrame to 1 when this frame completes the message.
  • Set finalFrame to 0 when more fragments will follow.

For an ordinary single-frame text message, set finalFrame to 1. WebSocket text data is UTF-8 on the wire.

Message fragmentation: Repeated calls with finalFrame set to 0 create fragments of the same text message. Complete the message with a final call that passes 1.

Returns 1 for success, 0 for failure.

top
SendFrameSbAsync (1)
function SendFrameSbAsync(sbToSend: IChilkatStringBuilder; finalFrame: Integer): IChilkatTask;
Introduced in version 9.5.0.70

Creates an asynchronous task to call the SendFrameSb method with the arguments provided.

Note: Async method event callbacks happen in the background thread. Accessing and updating UI elements existing in the main thread may require special considerations.

Returns nil on failure

top
SendPing
function SendPing(pingData: WideString): Integer;
Introduced in version 9.5.0.70

Sends a WebSocket Ping control frame. If pingData is non-empty, its UTF-8 bytes are included as the Ping payload.

WebSocket control-frame payloads are limited to 125 bytes. If the UTF-8 representation exceeds this limit, Chilkat truncates it to 125 bytes.

Ping/Pong behavior: A peer that receives a Ping is expected to send a Pong containing the same application data as soon as practical. Ping is useful for protocol-level liveness checks, but receiving a Pong does not by itself prove that the application running above the connection is healthy.

Returns 1 for success, 0 for failure.

More Information and Examples
top
SendPingAsync (1)
function SendPingAsync(pingData: WideString): IChilkatTask;
Introduced in version 9.5.0.70

Creates an asynchronous task to call the SendPing method with the arguments provided.

Note: Async method event callbacks happen in the background thread. Accessing and updating UI elements existing in the main thread may require special considerations.

Returns nil on failure

top
SendPong
function SendPong(): Integer;
Introduced in version 9.5.0.70

Sends a WebSocket Pong control frame.

When a Ping has been received and has not yet been answered, this method automatically uses the previously received Ping payload as the Pong payload, as required for a Ping response.

Manual response mode: This method is normally used when PingAutoRespond is 0 and NeedSendPong is 1. When automatic Ping handling is enabled, Chilkat sends the Pong internally.

Returns 1 for success, 0 for failure.

top
SendPongAsync (1)
function SendPongAsync(): IChilkatTask;
Introduced in version 9.5.0.70

Creates an asynchronous task to call the SendPong method with the arguments provided.

Note: Async method event callbacks happen in the background thread. Accessing and updating UI elements existing in the main thread may require special considerations.

Returns nil on failure

top
ShareConnection
function ShareConnection(ws: IChilkatWebSocket): Integer;
Introduced in version 11.0.0

Causes the calling WebSocket object to share the already-established WebSocket connection owned by ws.

This enables a bidirectional design in which separate WebSocket objects operate on the same connection—for example, one thread blocks in ReadFrame while another thread sends frames.

Concurrency model: Use this feature to separate the read path from the write path. The application remains responsible for coordinating object lifetime, shutdown, and higher-level message state. Avoid multiple concurrent readers or multiple unsynchronized writers unless the application provides its own coordination.

Returns 1 for success, 0 for failure.

top
UseConnection
function UseConnection(connection: IChilkatRest): Integer;
Introduced in version 9.5.0.70

Associates this WebSocket object with an existing, connected Rest object and prepares it for a client-side WebSocket session.

The opening WebSocket handshake is an HTTP GET upgrade request. Using Rest for the underlying connection allows the application to configure TLS, proxies, authentication, custom request headers, IPv6, socket options, bandwidth limits, and other connection features before the upgrade is performed.

Client-side API: Chilkat.WebSocket initiates connections to WebSocket servers. It does not listen for incoming connections or implement a WebSocket server endpoint.
Typical opening sequence
  1. Connect the Rest object to the server.
  2. Call UseConnection.
  3. Call AddClientHeaders.
  4. Send the HTTP GET request with the Rest object.
  5. Call ValidateServerHandshake.

Returns 1 for success, 0 for failure.

top
ValidateServerHandshake
function ValidateServerHandshake(): Integer;
Introduced in version 9.5.0.70

Validates the server's response to the WebSocket opening handshake sent through the associated Rest object.

Validation checks that the server accepted the HTTP upgrade and returned the expected WebSocket handshake response, including the value derived from the client's Sec-WebSocket-Key. If this method returns 1, the connection has entered the WebSocket protocol and data or control frames may be exchanged.

Call order: Call this method only after the Rest object has sent the opening GET request and received the server's response. A successful HTTP request alone does not establish a WebSocket session; the response must also pass this validation.

Returns 1 for success, 0 for failure.

More Information and Examples
top

Events

AbortCheck
procedure AbortCheck(ASender: TObject; out abort: Integer);

Enables a method call to be aborted by triggering the AbortCheck event at intervals defined by the HeartbeatMs property. If HeartbeatMs is set to its default value of 0, no events will occur. For instance, set HeartbeatMs to 200 to trigger 5 AbortCheck events per second.

More Information and Examples

Delphi ActiveX Event callback implementation:

procedure TForm1.websocketAbortCheck(ASender: TObject;  out abort: Integer);
begin
    // Application code goes here...
end;


procedure TForm1.Button1Click(Sender: TObject);
var
  websocket: TChilkatWebSocket;

begin
  websocket := TChilkatWebSocket.Create(Self);
  websocket.OnAbortCheck := websocketAbortCheck;
  // ...
top
PercentDone
procedure PercentDone(ASender: TObject; pctDone: Integer; out abort: Integer);

This provides the percentage completion for any method involving network communications or time-consuming processing, assuming the progress can be measured as a percentage. This event is triggered only when it's possible and logical to express the operation's progress as a percentage. The pctDone argument will range from 1 to 100. For methods that finish quickly, the number of PercentDone callbacks may vary, but the final callback will have pctDone equal to 100. For longer operations, callbacks will not exceed one per percentage point (e.g., 1, 2, 3, ..., 98, 99, 100).

The PercentDone callback also acts as an AbortCheck event. For fast methods where PercentDone fires, an AbortCheck event may not trigger since the PercentDone callback already provides an opportunity to abort. For longer operations, where time between PercentDone callbacks is extended, AbortCheck callbacks enable more responsive operation termination.

To abort the operation, set the abort output argument to 1. This will cause the method to terminate and return a failure status or corresponding failure value.

More Information and Examples

Delphi ActiveX Event callback implementation:

procedure TForm1.websocketPercentDone(ASender: TObject;  pctDone: Integer; out abort: Integer);
begin
    // Application code goes here...
end;


procedure TForm1.Button1Click(Sender: TObject);
var
  websocket: TChilkatWebSocket;

begin
  websocket := TChilkatWebSocket.Create(Self);
  websocket.OnPercentDone := websocketPercentDone;
  // ...
top
ProgressInfo
procedure ProgressInfo(ASender: TObject; const name: WideString; const value: WideString);

This event callback provides tag name/value pairs that detail what occurs during a method call. To discover existing tag names, create code to handle the event, emit the pairs, and review them. Most tag names are self-explanatory.

Note: Some Chilkat methods don't fire any ProgressInfo events.

More Information and Examples

Delphi ActiveX Event callback implementation:

procedure TForm1.websocketProgressInfo(ASender: TObject;  const name: WideString; const value: WideString);
begin
    // Application code goes here...
end;


procedure TForm1.Button1Click(Sender: TObject);
var
  websocket: TChilkatWebSocket;

begin
  websocket := TChilkatWebSocket.Create(Self);
  websocket.OnProgressInfo := websocketProgressInfo;
  // ...
top
TaskCompleted
procedure TaskCompleted(ASender: TObject; const task: IChilkatTask);

Called from the background thread when an asynchronous task completes.

More Information and Examples

Delphi ActiveX Event callback implementation:

procedure TForm1.websocketTaskCompleted(ASender: TObject;  const task: IChilkatTask);
begin
    // Application code goes here...
end;


procedure TForm1.Button1Click(Sender: TObject);
var
  websocket: TChilkatWebSocket;

begin
  websocket := TChilkatWebSocket.Create(Self);
  websocket.OnTaskCompleted := websocketTaskCompleted;
  // ...
top