Release Notes

30 Oct 2026: ver. 1.2.0

The user can hand the assistant a document. A paper clip next to the question box takes a PDF, an image or a text file, and the model reads it - which, together with an action, is a PDF filling a form without anybody retyping what is in it.

• Attachments (HelpChatAI.Attachments, RTL): .pdf and .png .jpg .jpeg .gif .webp travel as bytes in the block each API wants (Anthropic document/image, OpenAI a file part and an image_url data URI, Gemini inlineData); .txt .md .csv .json .xml .log .ini .yaml .yml are decoded when they arrive - BOM, else UTF-8, else the ANSI code page - and put in front of the question, fenced so the content of a file cannot read as an instruction. A .docx or an .xlsx is refused by name: no model reads one, and sending it anyway would look like it worked
• The paper clip, or a file dropped on the panel - anywhere on it, and more than one at a time. A chip per document above the question box, with the glyph of its kind, its size and an ✕, and a turning ring while the bytes go up
• Off until you turn it on: Settings.Attachments.Enabled is False, because what the user attaches leaves the machine. MaxCount, MaxSizeKB and MaxTotalKB bound the rest. The clip appears only when attachments are enabled and the configured provider can read documents, so docsearch and stub never promise what their answer could not deliver
• An attachment belongs to the conversation, not to the question: it is sent again with every later question, so a second question about the same document needs no second upload, and ↺ takes the documents away with the conversation. They live in memory and are never written to the conversation file on disk
• The panel draws the chips from the server (GET /api/attachments), not from its own memory: a page reload - a VCL style change recreates the window and reloads it - used to leave the bar empty while the documents kept going out with every question
• The file-type glyphs are inline SVG in the panel page (Material Design Icons, Apache 2.0): generic glyphs, no brand logo, and nothing new to ship
• CRM Demo\Docs holds two documents to try it with - a request for information as a PDF and the notes of the follow-up call - and both demos accept attachments. Attach the PDF, ask "create a lead from the attached request", and the model fills create_lead with what it read
• 271 tests, 25 of them new: the accepted and refused types, the three limits, text decoding, the blocks each of the three providers builds, and the endpoints over real HTTP

27 Oct 2026: ver. 1.1.1

The library did not change in this release: source is the one of 1.1.0, and so are the 246 tests. What changed is the FireMonkey sample application, which is now the whole application and not only its main form.

• The lead, proposal and proposal draft windows ported to FireMonkey, over the same bind sources as the VCL ones, so the FireMonkey demo registers the same three actions - open_screen, create_lead and draft_proposal. Four things FireMonkey does differently there, each worth knowing before porting something of your own: a TCardPanel is a TTabControl with TabPosition = None; a TRelativePanel that rearranges itself is Align plus a scroll box, and the five resize handlers simply disappear; MessageDlg answers in a callback, so what follows the question lives there; and the DOM of the old TWebBrowser is replaced by LoadFromStrings
• F1 works in those windows too. Help properties live on TStyledControl and a FireMonkey form has none, so each unit carries its keyword as a constant and OnGetContext reads it from the active form - which is what HandleKeyDown of the component is there for
• The side menu of the FireMonkey demo behaves like the VCL one: open until the user presses its button, then narrowed to its icons - and they are the icons of the VCL menu, read from the same image collection. None of the three modes of TMultiView does this on its own (Panel is permanent and hides the button it is given, Drawer and NavigationPane slide over the content and close again at the first click outside), so the pane is a docked Panel inside a layout whose width the button changes
• The proposal document moved to CRM Demo\common\uProposalReport.pas, plain RTL with no VCL and no FireMonkey in it, so the two demos build byte for byte the same invoice from the same code - and the VCL one is ninety lines lighter. On the way there the line titles gained a TNetEncoding.HTML.Encode they did not have: that text can come from the model

27 Oct 2026: ver. 1.1.0

• Caption and AssistantName on both components: the title of the window the chat opens in, and the name written in the header of the panel. Empty - the default - means the word of the current language, so an English application reads "Help" and "Assistant" and an Italian one "Aiuto" and "Assistente" without anybody writing them
• The header of the panel shows the icon of the bubble next to the name. Name and icon reach the page the way the colours do, through the transport and POST /api/assistant: an image list is an object of the framework, so only the client can know it
• The icons of the assistant moved to the engine (HelpChatAI.Assistant), where both frameworks can reach them. For the built-in ones the icon the page loads is the PNG itself, with its transparency, and no drawing in between
• FireMonkey caught up with the VCL: the bubble is round and wears the icon, and Images, ImageIndex and ImageName are published there too, with the four names in the Object Inspector
• Fixed, both found by running the new FireMonkey demo: the FMX bubble was placed outside the window the first time the form was resized (FireMonkey computes the anchor rules once, against the parent the control has at that moment, and it had none yet), and a relative DocIndexFile was resolved against the current directory instead of the executable, so the documentation index was found or not depending on who started the application
• Two sample applications, CRM Demo\VCL and CRM Demo\FMX, sharing one data module and one manual. The FireMonkey one is the main form alone - the seven pages, the same bind sources, TFmxHelpChatAI with a HelpKeyword per tab - and needs Delphi 12 or later, because TFmxHelpChatAI starts there
• 246 tests, and a build matrix of 12: VCL on Delphi 10.4 to 13, FMX on 12 and 13, Win32 and Win64

25 Oct 2026: ver. 1.0.0

• First release: in-app AI help chat for VCL (Delphi 10.4+) and FMX (Delphi 12+) applications
• Engine (RTL only) with the providers docsearch (local documentation index, no key needed), claude (Anthropic), openai (Chat Completions, and with it Azure, Groq, OpenRouter, Mistral, Ollama...) and gemini (Google): all three models stream and can call the actions of the application, grounded on the documentation and on the screen context
• TVclHelpChatAI (TEdgeBrowser) and TFmxHelpChatAI (TWebBrowser): chat bubble, F1 contextual help, chat panel embeddable in any container, colours from the VCL style
• An assistant that acts: the application registers the actions it may call, with confirmation for the ones that change data
• Question dictation, design-time live preview and configuration check
• HelpChatAI server: engine, index and API key on a server, remote transport chosen in the configuration file
• HelpIndexBuilder: builds the documentation index (help-index.json) from a folder of Markdown files
• Packages for Delphi 10.4, 11, 12 and 13, DUnitX tests and installer
• A sample application with the component in it: the Windows 10 CRM demo of Embarcadero, with a manual of its own, F1 on every screen and three actions the assistant can run