Turn a Screenshot Into a Delphi Web Page

· Components
Turn a Screenshot Into a Delphi Web Page

The best specification you will ever get for a screen is a picture of the screen it replaces. It is also the one thing a code generator cannot read. sgcWebSockets 2026.10 adds an AI page generator to the sgcHTML visual designer: describe the page in a sentence, or hand it a screenshot, and it builds the page out of your components.

What comes out is not markup and not a framework. It is ordinary sgcHTML components, owned by the form, editable in the Object Inspector, exportable as Object Pascal that compiles with the designer uninstalled.

Describe It

In the IDE the prompt box sits in the toolbar of the Web Design tab, next to Generate and Refine. In an application that hosts the designer itself, it is a component:

uses
  sgcHTMLDesign_AI;

FGenerator := TsgcHTMLDesignAIGenerator.Create(Self);
FGenerator.Surface := oSurface;
FGenerator.APIKey := ReadSetting('openai.key');
FGenerator.Model := 'gpt-4o-mini';

oErrors := TStringList.Create;
try
  vTree := FGenerator.Generate(
    'an orders page with a search box, a grid of this month''s orders ' +
    'and a chart of the totals by customer', oErrors);
  if vTree <> '' then
    FGenerator.Apply(vTree, oErrors);
finally
  oErrors.Free;
end;

Or Photograph It

The same generator reads a picture. A screenshot of the application being replaced, a mockup out of a design tool, a photograph of a sketch on a whiteboard:

vTree := FGenerator.GenerateFromImage('C:\shots\orders.png',
  'ignore the sidebar', oErrors);

The description is optional there and narrows what to look at rather than describing the page. It reads the layout, the headings, the columns of a table and the labels of a form out of the image, and writes what it reads into the captions. In the designer the button is From image, and what comes back is the same candidate with the same Accept and Discard.

It Answers a Design Tree, Not Code

This is the part that makes the difference between a toy and something you would let near a project. The model never writes markup and never writes Pascal. It answers a design tree: the same JSON the design surface itself saves and loads.

{"version":1,"nodes":[
  {"kind":"section","caption":"Orders","children":[
    {"kind":"row","children":[
      {"kind":"column","width":12,"children":[
        {"kind":"component","class":"TsgcHTMLComponent_Grid",
         "props":{"ElementID":"orders","Title":"Orders of the month"}}
      ]}]}]}]}

Five node kinds, and one of them names a component class. Which is where the boundaries are.

Three Boundaries, and None of Them Is the Prompt

The schema comes from your registry. The request carries a JSON schema whose class enumeration is exactly the set of registered components, narrowed further by the Classes property. The model cannot name a class that does not exist, or one you did not offer.

The answer is normalised. NormalizeTree drops every key it does not know, drops a node whose class is not registered, caps the tree at MaxNodes and rewrites the property list into the shape the surface reads.

The surface reads strictly. LoadTreeJSON skips and reports an unknown node kind, an unregistered class, a property that does not exist or is not writable, and a value the property refuses. You always get the list of what did not survive.

Markup is the one thing a generated tree is never trusted with. An html node is loaded as escaped text unless AllowRawHTML is switched on, so a model that was talked into answering a script puts that script on the page as visible text and nothing else.

Candidate First, Page Second

Generate starts from nothing. Refine starts from the page as it is now and asks for the whole page after the change, never a patch, so the two can be compared. Neither touches the page: they answer a tree, and Apply is what puts it on the surface. That is what keeps Accept and Discard honest, and Accept keeps one step of undo.

Where the Key Lives

On your machine, not in the project. The settings page is Tools › Options › Third Party › sgcHTML AI page generator: provider, API key, model, an optional base URL, the language the captions are asked in and the largest tree that will be accepted. The key is kept per user and never written into the .dfm, the .dproj or the page, which is what keeps it out of source control.

Upgrading

The generator is part of sgcHTML. The provider path uses the AI units, which are Windows only: without them the component still compiles and answers with one line saying there is no provider, so a project that uses it builds on every platform. Nothing of the page being designed is sent anywhere except what Refine needs, which is the page itself.

Watch It

There is a short video of this on the eSeGeCe channel.

Questions, feedback or migration help? Get in touch — you will get a reply from the people who wrote the code.