FormsLang 1.5.0 — Adjustable workspaces

FormsLang 1.5.0 gives the conversion workspace adjustable panels and a dedicated code focus mode.

• Drag the dividers to resize the units list, source/proposal comparison and evidence panel. Dividers also support keyboard resizing.
• Show or collapse supporting sections from Layout, collapse the navigation to icons, and expand the code with Focus. Exit Focus restores the previous workspace.
• Layout preferences stay in the current browser and can be reset. Sizes adapt to the window, including shorter laptop screens.
• Dark and light themes keep the corporate interface, accessible controls and reduced-motion support.
• README screenshots now show the actual updated Workbench with the synthetic showcase.
• Fixed a JavaScript scope error in the export dialog after a successful ZIP build.

The CLI, local HTTP API, session format and export layout remain compatible within 1.x. Save pending review edits before closing or upgrading; drafts are held in tab memory.

The attached Windows NSIS and MSI installers are the exact artifacts tested by Installer acceptance, including upgrade from 1.4.0 with a saved review. See quality acceptance for verification evidence and hashes.

The UI checks use synthetic fixtures and an offline test provider. They do not establish Oracle Forms/APEX runtime migration correctness.

Full changelog

FormsLang 1.4.0 - Corporate Workbench

FormsLang 1.4.0 refreshes the Workbench with a corporate graphite-and-amber interface, persistent navigation and a focused review workspace.

• Dark and light themes, remembered locally.
• Clearer unit filters, Forms/APEX comparison, evidence and review decisions.
• Responsive navigation and code views for desktop, tablet and phone.
• Subtle transitions, reduced-motion support and keyboard navigation.
• Existing session guards, saved decisions and in-memory drafts remain part of the same workflow.

The Windows installers below are the exact artifacts tested by the Installer acceptance workflow, including upgrade from 1.3.2 and preservation of a saved review and export. Automated acceptance uses synthetic fixtures; it does not establish new Oracle Forms/APEX runtime behavior.

Download the .exe for the Windows setup wizard or the .msi for MSI-based installation.

Full changelog · Changes since 1.3.2

FormsLang 1.3.2

Changed

• Conversion review has Compare, Forms source, APEX proposal and Evidence & tests
  views, more code space, persistent decision controls and a responsive unit drawer.
  Modal keyboard focus stays inside the dialog and returns to its opener.
• Blueprint uses a compact application header, sticky navigation, owner-qualified
  rule candidates, component history and direct links to the originating code unit.
  Source can be copied; AI sections expand individually. README includes current
  Blueprint and conversion screenshots from the synthetic showcase.
• Blueprint AI explanations run in the background with elapsed time and reconnect
  after modal close/reopen or browser reload while the app remains open. Eight
  requests/results are retained in memory, scoped to session, user, source/engine
  revision and provider. Discard suppresses the result without pretending to kill
  the provider. Synchronous API calls remain supported.
• Explorer lists and neighbors omit unselected source bodies; repeated reads reuse
  a snapshot invalidated by local or external SQLite writes. Source connections
  prioritize diverse relationship kinds. Individual AI context is explicitly bounded.

Fixed

• Conversion edits and architecture-review drafts survive navigation, filtering,
  polling and late save responses. Unsaved state, explicit discard and unload
  warnings make the in-memory draft lifetime clear.
• Delayed responses cannot overwrite another modal, selected unit or newer AI
  request. Polling is serialized; cancelling a failed discard resumes status checks.
• Workbench requests carry an opaque session/user context guard to prevent stale
  conversion decisions and Blueprint actions reaching a different open session.
  Existing authorization, CSRF and source-revision checks remain in force.
• Overlapping Blueprint/conversion provider jobs are refused; repeated identical
  AI requests are reused. Provider errors are sanitized and do not trigger fallback.

Added

• Reproducible isolated Edge/Chromium acceptance script with real screenshots,
  draft/review/navigation/download checks and desktop/tablet/phone layouts.
  New JavaScript and backend regression tests cover request races and isolation.

FormsLang 1.3.1 - Guided Blueprint and APEX key confirmation

Changed

• Blueprint is now a guided reading workflow: Understand, Inspect & decide,
  and Modernization plan. Source-linked connection diagrams, a prioritized code
  reading queue and plain-language recommendations replace the initial metric
  dump. Review fields and implementation coverage appear when needed.
• The standalone Blueprint report leads with observed connections, decisions
  to investigate and proposed target architecture. Component inspection includes
  decoded source context when available, with explicit truncation limits.

Added

• Application-level AI architecture briefings, requested explicitly through the
  configured provider. Anonymous graph context is mapped back to local component
  links; malformed or unknown references are rejected. Briefings remain proposals
  and can be saved separately as HTML. No AI-generated scores or approvals.
• Confirm or withdraw a block's key in the APEX export dialog, using the columns
  actually placed on the page. CLI and Workbench now share the same validation
  gate and record reviewer identity; the export explains the resulting bindings.

Analysis boundaries

Connection arrows represent observed source references, not execution order. AI briefings are unapproved proposals based on anonymized structural evidence; they cannot establish business semantics or runtime parity. Architecture decisions and implementation coverage remain human responsibilities.

FormsLang 1.3.0 - Modernization Blueprint

Added

• Modernization Blueprint: deterministic application knowledge, shared
  dependencies, business-rule candidates, API reuse ranking, optional enterprise
  naming patterns and supplied database/PL/SQL metadata. formslang blueprint
  writes reproducible JSON, standalone HTML, Markdown and Mermaid artifacts.

• Blueprint in the existing Workbench: filtered dependency exploration,
  source evidence, architecture review with stale-decision detection, separately
  evidenced modernization coverage and optional anonymized AI explanation.
  Existing conversion approvals, risk/readiness formulas and APEX exports remain
  separate. See the Blueprint guide.

• A block whose key a reviewer confirmed exports as a form APEX fetches
  and saves. formslang apex export --key BLOCK=COLUMN records that the
  column identifies one row of the block's base table; the block's region
  then becomes a form region over that table, its items bind to their
  columns, and the page gets a formInitialization process before the
  header and a formAutoRowProcessing process at sequence 1000 -- behind
  every approved conversion, so a trigger the reviewer enabled has already
  filled its column before the row is written. --forget-key withdraws the
  confirmation and the region goes back to exactly what it was. Nothing
  binds on its own: the Forms PrimaryKey flag is offered as a hint and
  never acted on, because a wrong key raises no error -- it silently
  fetches and saves the wrong row -- so the answer is stored with a name
  and a date. A block with no confirmation is unchanged, byte for byte,
  and the export now reports both halves: Bound with the column and who
  confirmed it, Unbound with the reason and the flag that would bind it.
  Only a single-record block whose database items all sit in one region of
  their own qualifies for now.

• A bound region gets a Create button and a Save button, not one Save.
  APEX takes insert-or-update from the pressed button's Database Action and
  not from whether the form found a row, so a single button always updates
  and the page could never create a record. Create shows when the key item
  is null, Save when it is not, and one write process runs for either. The
  submit branch is a redirect back to the page: a Show Only branch is
  refused at run time on a page whose Reload on Submit is Only for Success,
  and the submit then saves nothing without showing an error. Both facts
  were found with the page open in a browser -- apex validate and
  apex import accept either spelling.

• An approved Forms validation exports as an APEX validation. A
  WHEN-VALIDATE-ITEM or WHEN-VALIDATE-RECORD the reviewer approved
  becomes a page validation of type PL/SQL Error -- it passes when the
  approved code runs without raising, exactly as the Forms trigger did --
  and it ships enabled, so the rule is enforced after the import instead of
  arriving as an inert process. An item rule points at the page item the
  Forms item became; a record rule, or an item that became an Interactive
  Grid column, shows its error in the notification (a validation pointing at
  an item the page does not declare fails the import with
  REFERENCE_NOT_FOUND).

• An exported validation carries the wording the rule already had. APEX
  prints the validation's own error message and never the error the code
  raises, so the sentence is read out of the approved code
  (raise_application_error, apex_error.add_error) or, when that code
  raises without saying anything, out of the MESSAGE() of the Forms
  trigger it came from. The manifest records which of the two it was. A
  rule whose message is built at run time ('invalid: ' || :ITEM), or
  whose source says two different things, keeps the placeholder and gets
  the reason in its component comments: half a sentence in front of a user
  is worse than an honest placeholder.

• formslang apex validate runs without a database. With no target
  configured -- or with the new --offline flag, which ignores one that
  is -- SQLcl compiles the exported package against the APEXlang grammar
  bundled in its own apexlang-compiler.jar: no connection, no workspace,
  no credentials. A narrower check than a connected validate, and still
  Oracle's verdict rather than FormsLang's. apex import is unchanged and
  still requires a workspace.

• CI validates the showcase export on every push, and proves the gate can
  fail: a copy of the ZIP with one region type replaced by an invalid one
  must be rejected by the same command. The same job exports the module a
  second time with its rules approved, so the validations are compiled by
  Oracle too, and patches one of them to point at a page item that does not
  exist -- which must fail.

• A demo-sized fixture, tests/fixtures/minicase/. The showcase is a
  coverage bench -- 5 blocks, 78 items, 55 triggers, 59 review units -- and
  is the wrong module to walk anyone through. MINI_PRODUTO is one block,
  8 items, 6 triggers and six review units, and still covers every element
  the smallest complete case has to show: a restricted query, an insert
  that assigns the key, required items, a rule spanning two fields, and a
  failure a user can understand. Two of its rules carry their own sentence
  and one raises silently, so a single module exercises both origins an
  exported error message can have. It round-trips through Oracle Forms
  14.1.2 with no structural differences. CI guards its shape on every OS
  and puts its package through apex validate --offline beside the
  showcase's.

Fixed

• A saved APEX password is found whether the connection is written as
  host:port/service or as the JDBC URL for it. The account name in the
  credential store is derived from the connection, so the two spellings of
  one database used to hide each other's password and the workbench asked
  for it again.
• The Diff report labels added and removed program units with their kind,
  as modified ones already were, so a package specification and its body
  removed together no longer appear as two identical names.

Changed

• The installer acceptance workflow reads the candidate version from the
  checkout and defaults the baseline to the latest published release. Its
  build steps moved to a reusable workflow (build-installers.yml) so
  acceptance and release runs freeze the same binaries.
• The installed-engine check raises on every failed step instead of relying
  on assert, finds the fixture relative to itself, verifies the unit it
  approved rather than the first in the list, and records only what each
  phase actually checked.
• A test requires every version declaration to agree: pyproject.toml,
  the __init__ fallback, package.json, tauri.conf.json, Cargo.toml
  and both lock files.
• The README build recipe uses the same spec file as CI; the release
  procedure is written down in docs/releasing.md.

Blueprint analysis boundaries

• Business rules are conservative static candidates, not verified business
  semantics. Dynamic SQL, unresolved symbols, callee behavior and external callers
  can remain unknown. API ranking measures observed reuse, not API suitability.
• Architecture recommendations require human review. Modernization coverage is
  evidence-backed review tracking, not verified functional parity. No live Oracle
  application or database validation was performed for the Blueprint feature.

FormsLang 1.2.2

FormsLang 1.2.2

Melhorias de confiabilidade dos recursos existentes, sem novos recursos de produto.

• Corrigido o Diff para distinguir especificação e corpo de pacotes com o mesmo nome, sem ocultar alterações ou remoções.
• O empacotamento recusa metadados de versão inconsistentes no motor.
• 949 testes passaram em cada uma das oito combinações Windows/Linux e Python 3.10–3.13; Ruff e exportação determinística também passaram.
• EXE (NSIS) e MSI passaram em instalação limpa da 1.2.1 e atualização para 1.2.2, preservação da aprovação, exportação reproduzível e abertura da janela nativa.

Publicada a pedido do usuário para download e teste. A comparação real Forms/APEX do showcase permanece pendente com o usuário. Não foi executada importação no banco e não se afirma equivalência funcional ou visual completa.

Downloads

• FormsLang_1.2.2_x64-setup.exe: instalador Windows x64.
• FormsLang_1.2.2_x64_en-US.msi: alternativa MSI Windows x64.

Código dos binários testados: 6fc9f5c2f114244fa3b6b3742bb78a6b99debd91.

Testes de regressão · Aceitação dos instaladores

SHA-256:

EXE 340CEC67C51FF9BBCC59704B4AA403B48671581AF5920BC589DD7AB841748D16
MSI 8E1F44C4057E9315041E1C4692DF4E125745AF9A6E0327F3AD41254F6069ED6E

FormsLang 1.2.1

FormsLang 1.2.1 hardens the existing review workflow. No new product features.

• Preserve short executable bodies such as EXIT_FORM; and CLEAR_FORM;.
• Keep package specifications and bodies as separate review tasks.
• Refuse changed source before it can reuse an earlier approval.
• Preserve current source when a same-name upload fails.
• Keep header actions reachable at narrower desktop widths.
• Fix frozen-engine packaging and version metadata.

Upgrade: reopen the original unchanged XML/FMB in its existing output directory
to recover omitted units as pending review. Existing decisions are preserved.
Opening only the session database does not rescan source. Use a separate -o
directory for a changed revision.

Validation: 945 tests passed on Windows/Python 3.13; one Windows symlink test was
skipped for lack of symlink privileges. Ruff passed. Chrome checks covered
1100/1280/1380 px, Doc, Preview, ZIP export and approval persistence after reload.
The packaged engine reports 1.2.1 and produces identical ZIP bytes on repeated
exports from the same session.

SQLcl validated the packaged engine's ZIP successfully in /nolog mode.
The MSI was extracted administratively into an isolated QA directory; its
engine matches the tested binary byte for byte and reports version 1.2.1.
SHA256SUMS.txt accompanies the Windows NSIS and MSI installers.

All 10 CI jobs passed for commit 370e639: Windows and Ubuntu with Python
3.10, 3.11, 3.12 and 3.13, Ruff, and deterministic showcase export.
CI evidence: https://github.com/B2DEV-TECH/FormsLang/actions/runs/34006842599

These checks do not certify clean-machine installer upgrades or full runtime
equivalence with production Forms modules. The real-corpus and Forms/APEX
functional comparison remain pending; see docs/quality-acceptance.md.

FormsLang 1.2.0

The fidelity release. A Forms screen now lands on the APEX grid where Forms drew it — each control on the column its x maps to, gaps kept, labels beside their fields with the room they had, toolbar buttons side by side, initial values filled in — plus an opt-in AI layout assistant for the regions the deterministic rules cannot lay out cleanly.

What is new

• Grid placement from x. A control starts on the grid column its Forms x maps to and spans the columns its width covers; the whitespace Forms drew before it stays an empty column. When two controls round onto the same column the second moves right; a row too crowded for twelve columns continues on the next grid row, and the controls after the wrapped one follow it there, keeping their distance. Every concession is recorded on the control in the mapping report (pushed, wrapped, shrunk, label-narrow, label-above).
• Labels beside their fields. labelColumnSpan is in grid columns and comes from the room the prompt takes in Forms; a row that cannot give every label a column puts all of its labels above, one rhythm per row. A caption right of or below a field becomes a label above it, no longer a floating label that read as a placeholder.
• Static defaults. A literal InitializeValue becomes the item's default and fills the field on render. On a radio group or select list the default is written only when it is one of the choices — APEX would otherwise add it as an extra, selected choice; a value that is a choice's label takes that choice's return value, and the report says so.
• Toolbars keep adjacent buttons in one grid cell, as on the Forms toolbar. Buttons render as plain buttons wired for a dynamic action, not submits. A required check box is left optional, with a note: a required APEX check box must be checked, while Forms only meant "has a value".
• AI layout assistant, opt-in per export (--ai-layout on the CLI, a checkbox in the export dialog). Only the hard regions are sent to the provider configured in Settings — those with a control the rules had to push, wrap, narrow or relabel, or a Forms row of five or more controls — with the region's size and each control's name, kind, type, geometry, caption and the rules' own placement; never column names, code or data. The plan is validated (every control exactly once, columns 1..12, no overlaps, every label narrower than its field) and applied to the one layout model the export and the preview share. A rejected, offline or failed answer keeps the rules' placement, and the manifest says what happened under layout.ai_layout. The plan is cached on the session and replayed while the layout is unchanged, so the export stays deterministic; the enterprise egress policy is checked before any request leaves the machine.
• The preview draws the default inside the field, the radio button it selects, and the label's exact share of its cell.

Verified on APEX 26.1.0

The showcase module was exported, validated, imported into a dedicated application and rendered through ORDS as a temporary end user. Against the 1.1.0 export of the same page: empty grid columns kept as whitespace 0 → 30; labels beside their field 23 → 28; floating labels 9 → 2 (the two check boxes only); required check boxes 1 → 0; the TP_STATUS radio group renders its three buttons with the Forms initial value selected and the TP_UNIDADE list preselected; 35 buttons as type="button"; no error banner, no LABEL_COLUMN_SPAN_TOO_BIG, no ORA- error. Showcase totals: 72 visible controls, 46 faithful / 26 approximation / 0 unsupported (14 toolbar controls that flow inline, 6 fields of an eight-field row moved or wrapped, 2 captions right/below now above, 2 boilerplate prompts, 1 radio group without return values, 1 required check box); 21 groups, 15 / 6 / 0. Test suite: 928 passed, 1 skipped.

The geometry rules, the matrix, the before/after table and the assistant's contract are in docs/layout-mapping-matrix.md.

Known limitations

Positions are kept to the column, not the pixel; a row wider than twelve columns is redrawn as two grid rows (or as the assistant proposes); toolbars flow inline; captions right of or below a field become labels above it; initial values that are Forms expressions ($$DATE$$, :GLOBAL.x) are notes, not computations; the assistant was exercised against a scripted provider in the test suite, not against a hosted model on the showcase.

Install

Windows: FormsLang_1.2.0_x64-setup.exe (NSIS) or FormsLang_1.2.0_x64_en-US.msi. Python: pip install -e . from the tag. Full changelog: CHANGELOG.md.

FormsLang 1.1.0

The layout release. A Forms screen now becomes native APEX components that keep its structure, with a per-element mapping report in every export.

What is new

• Native layout. Content canvases, frames and tab pages become regions, sub-regions and tab pages on the Universal Theme 12-column grid; rows are detected from the Forms geometry, column spans follow each item's share of its parent, the label keeps its own share of the row, and items drawn beside or below a frame keep their vertical order. No custom JavaScript, no CSS, no absolute positioning.
• Interactive Grids. A multi-record block on a table becomes an interactiveGrid region: one column per item in the order Forms draws the record, headings from the prompts, native column types, primary key, widths, required and max length, hidden database items as hidden columns. Editing stays off until the block's DML is confirmed; no table binding is invented.
• Native item types with their Forms properties. datePicker and numberField with the Forms format mask (right-aligned numbers), textarea with width and height from the item box, checkbox with the item's checked/unchecked values, radioGroup with the buttons per row and no empty choice, selectList on a shared static LOV, read-only for disabled items, text case, help text from hint and tooltip.
• Template options as native properties: t-Form--stretchInputs on form regions, t-IRR-region--hideHeader on a grid inside a captioned frame. Stacked canvases and secondary windows become inline dialogs; toolbars flow inline; boilerplate text and rectangles become static regions.
• Layout mapping report in apexlang-manifest.json: for every visible Forms control, its source identity and geometry, the component it became and where it sits on the grid, the rule applied, the properties preserved, the approximations, the unsupported mappings, and a faithful / approximation / unsupported status with explicit denominators. Never a score.
• Preview draws the planned APEX layout from the same resolved model the export writes, with Interactive Grids, date and number shapes and a fidelity badge per control.
• Render check without a public page: examples/verify/apex_render_check.py logs in as a temporary end user it creates and removes, fetches the imported page through ORDS and inspects the HTML.

Verified on APEX 26.1.0

The synthetic showcase module was exported, validated (Validation successful), imported into a dedicated development application, checked in the APEX dictionary and rendered through ORDS: 13 regions (9 standard, 3 Interactive Grids with their headings in Forms order, 1 tabs region with 5 pages), 3 date pickers, 15 number fields, textareas at 5x84 and 6x120 characters, no error banner, no LABEL_COLUMN_SPAN_TOO_BIG, no absolute positioning, no layout script. Showcase totals: 72 visible controls, 48 faithful / 24 approximation / 0 unsupported; 21 groups, 15 / 6 / 0.

The mapping matrix, the geometry rules, the before/after of the showcase page and the reproduction commands are in docs/layout-mapping-matrix.md. The render-time runbook is in docs/apex-import-verification.md.

Known limitations

Exact Forms pixels become rows and twelfths of a row; toolbars flow inline; captions right of or below a field float inside it; stacked canvases become inline dialogs without the dynamic action that opens them; Interactive Grids are read-only until the block's DML is confirmed; record-group LOVs are named, never generated; Image, Bean Area, OLE, ActiveX, VBX, Sound, Tree, Chart and custom items have no native component and are reported as unsupported with a placeholder.

Install

Windows: FormsLang_1.1.0_x64-setup.exe (NSIS) or FormsLang_1.1.0_x64_en-US.msi. Python: pip install -e . from the tag. Full changelog: CHANGELOG.md.

FormsLang 1.0.0

The first stable release of FormsLang: convert, document, diff and version Oracle Forms modules, and hand the resulting APEX 26.1 application to a pipeline. The CLI, the session file, the export layout and the workbench's local HTTP API are promised stable within 1.x.

Installers

• FormsLang_1.0.0_x64-setup.exe — Windows setup (NSIS)
• FormsLang_1.0.0_x64_en-US.msi — Windows installer (MSI)

Both bundle the engine and nothing else. Opening .fmb files still needs your own licensed Oracle Forms install; Forms2XML .xml files need nothing.

What's new

• formslang export <session.db> — the headless twin of the workbench's Export APEX 26.1 button: same exporter, same choices (remembered on the session), same bytes. --json for tooling.
• formslang apex validate|import <zip> — SQLcl driven from a terminal or CI. Target from flags, FORMSLANG_APEX_CONNECT/FORMSLANG_APEX_USER or Settings; password from FORMSLANG_APEX_PASSWORD, the OS credential store or a hidden prompt — never a command-line argument. Exit 1 when SQLcl prints APEXlang Compile Errors with exit 0.
• Deterministic exports — an unchanged session exports byte-identical ZIPs: name-ordered entries, fixed timestamps, one checksum salt per session. Rebuild, cache and diff what was reviewed.
• Export and Import dialogs show the command line that reproduces them, and the export dialog pre-fills the previous export's choices.
• docs/ci-cd.md + examples/ci/formslang-apex.yml — the pipeline contract and a complete GitHub Actions workflow (export → validate → import on main, plus a structural formslang diff job on pull requests).
• MultiLine="true" text items export as textarea.
• Oracle Forms homes under C:\Oracle are found with no ORACLE_HOME set (e.g. C:\Oracle\FR1412).
• Multi-user mode as a saved setting in the Settings screen, with the first-Owner status and a terminal shortcut for formslang auth bootstrap-owner.
• docs/apex-import-verification.md — the repeatable render-time check through ORDS for the class of defect apex validate cannot see.
• README rewritten for 1.0: CLI reference, versioning workflow, CI/CD, complete environment-variable table, architecture map.

Fixed

• A hidden-label item 1 or 2 grid columns wide failed to render in App Builder (LABEL_COLUMN_SPAN_TOO_BIG); hidden labels now emit labelColumnSpan: 0.

Full details in CHANGELOG.md.