Erik's ToolBox Documentation
Index

RDL Editor - The Safety Net

The editor holds the entire layout model in memory, so it can protect you from the mistakes that aren't visible at the point where you make them. Report Builder can't warn you that deleting a column breaks the page header three sections away — this editor can.

Reference-aware delete protection

BC layouts are full of hidden helper textboxes: the page header shows the document number by referencing =ReportItems!HiddenDocumentNo.Value, where HiddenDocumentNo is an invisible textbox parked in the body or inside a line-table cell. Hidden does not mean unused — deleting one breaks the report with:

The Value expression for the text box refers to the report item … Report item expressions in a Page Header or Footer can only refer to report items within the same ReportSection.

Whenever you delete an item, a table row, or a table column, the editor scans every expression in the layout for ReportItems! references to anything inside what you're deleting. If there are any, you get the list of exactly what would break, and three choices:

  • Hide instead (recommended) — the classic hide-first, delete-later discipline as a button. Hidden items still evaluate, so every reference keeps working.
  • Delete anyway — you know better.
  • Cancel.

"Referenced by"

Select any named textbox or cell and the property pane shows who depends on it: 🔗 Referenced by: Page Header / Textbox42 (Value)… — so you know before renaming or deleting. This replaces the tribal-knowledge doc note ("do not delete HiddenCustomerAddress5!") with the editor just telling you.

Expression lints

Inline ⚠ hints appear under a Value when it breaks a renderer rule:

Lint Why
Fields! used in a page header/footer Page bands can't read dataset fields — use the hidden-body-textbox + ReportItems! pattern
More than one ReportItems! reference in one header/footer expression Renderer limitation — split into separate textboxes
Globals!PageNumber combined with .ToString / Format() in a page band Word export freezes such page numbers to one value — use a plain Globals!PageNumber textbox
ReportItems!X where no textbox named X exists The reference is already broken (typo, or the helper was deleted before this editor existed)

Printable-width guardrails

The #1 cause of "every other PDF page is blank" is content wider than the printable area. Four layers of defense:

  1. The width budget readout in page properties (chapter 6).
  2. A red dashed boundary + warning chip on any band whose content — including hidden items — extends past the printable width.
  3. An immediate toast warning when a table structure edit (the "just add one more column" trap) pushes the table past the boundary.
  4. Drag clamping and band auto-grow, so interactive editing can't create out-of-bounds geometry in the first place.

Hidden-item discovery

Do not trust visual emptiness. The Structure tab badges every statically hidden item, and 👁 Highlight hidden items outlines them in orange on the canvas — so the helper textboxes, hidden rows, and off-to-the-side leftovers are always findable.

The fidelity guarantee

Underneath all of it, the editor's core invariant: a zero-edit open→save changes nothing, and an edit changes only what you edited. Charts, subreports, custom properties, designer metadata — everything without an editor — is preserved byte-faithfully in place. This is enforced mechanically against all 568 stock BC28 layouts before every release. You can open a production invoice layout, fix one border, and save with confidence.