Sgcwebsockets

sgcWebSockets

This is the index for sgcWebSockets. It holds the full component list, the edition matrix and the version history, and nothing else. The detailed API, the types and the examples live in seventeen companion skills, one per area of the library.

Use this skill to answer "which component do I need" and "is it in my edition". Then load the skill that owns that component and work there.

Finding the right component

reference/components-index.md lists all 222 components with their unit, their edition, and the skill that documents each one. That last column is the routing: find the component, load that skill.

If you already know roughly what you are doing, go straight to the skill:

The sgcHTML widgets split six ways: -html-layout for page structure, -html-forms for inputs, -html-data for grids and schedulers, -html-charts for charts and indicators, -html-ui for modals and media, and -html-auth for login and chat panels.

Two rules that apply everywhere

Nothing compiles without the right unit. Every API page states its unit: at the top, and that unit must be in your uses clause. This is the single most common reason generated sgcWebSockets code fails to build.

Most protocol and API components are not standalone. They attach to a TsgcWebSocketClient or a TsgcWebSocketServer through a Client or Server property, and one transport carries one protocol. The exceptions are the IoT clients and the standalone HTTP clients, which own their own transport and are started with Active := True.

Editions

concepts/editions-and-features.md groups every component by the minimum edition that includes it. Check it before recommending a component, because the answer to "the component is not on my palette" is usually the edition rather than the installation.

sgcHTML is the narrowest: All-Access only, Indy required, and unavailable on Android and iOS.

What is documented, and what is not

These skills carry the public and published API: properties, events, methods, their types, and the unit each component lives in. Method bodies, private fields and protected members are deliberately excluded, so the skills describe the shape of the library without exposing its source.

That has one consequence worth knowing when you use them: a value that only ever appears as a method parameter may not have its own type page. If you need an enumeration's values and cannot find the page, say so rather than guessing an identifier, because a plausible-looking wrong constant costs more time than the question does.

Version history

reference/history.md lists what changed in each release. It is the place to check when an API in a customer's code does not match what these skills describe, because the answer is often that they are on an older build.

Routing

• Find a component: reference/components-index.md lists every component, its unit, its edition, and the skill that documents it.
• Then load that skill: the API page, the option / enum / event type pages and the examples for a component live in the skill named in its row, not here.
• Uses clause: add the component's unit: value to your uses clause. Nothing compiles without it.
• Editions: concepts/editions-and-features.md groups every component by the minimum edition that includes it.
• Concepts: concepts/overview.md (getting started + uses-clause rule).
• Version history: reference/history.md lists what changed in each sgcWebSockets release.