DYNAMICTEXT Attribute binding inside LISTVIEW is silently dropped, leaving orphaned template parameter and causing Studio Pro NullReferenceException

[kovacoj]

Summary

When a DYNAMICTEXT widget inside a LISTVIEW is created or modified through mxcli with an attribute binding, mxcli reports success, but the binding does not appear to be persisted correctly.

The resulting page keeps a text template such as:

Content: '{1}'

but the corresponding attribute/template parameter binding is missing.

This leaves an orphaned template placeholder and causes Mendix Studio Pro to throw a System.NullReferenceException when opening/selecting the affected widget in the page editor.

This looks like a validation/persistence issue in mxcli: either the binding should be persisted correctly, or mxcli should reject the unsupported syntax with a clear validation error. It should not silently write a broken model state.

Environment

• Mendix Studio Pro version: 10.23.0
• mxcli version: nightly (2026-06-07T12:42:15Z)
• Context: mxcli used through OpenCode
• OS: TODO: add your OS here, e.g. Windows 11 / WSL / Linux / macOS

Steps to reproduce

1. Create or modify a page containing a LISTVIEW.

2. Inside the list item template, add a DYNAMICTEXT widget intended to display an entity attribute, for example:

   DYNAMICTEXT txtFirstName (
     Attribute: Firstname
   )
   

   or equivalently a dynamic text template using content parameters, for example:

   DYNAMICTEXT txtFirstName (
     Content: '{1}',
     ContentParams: [{1} = Firstname]
   )
   

3. Run mxcli validation/check.

   mxcli check

4. Run the mxcli command that writes the model.

   mxcli exec <script-or-command>

5. Re-describe or inspect the affected page after the write.

6. Observe that the persisted widget no longer contains the attribute/template binding. It only keeps something equivalent to:

   DYNAMICTEXT txtFirstName (
     Content: '{1}'
   )
   

7. Open the project in Mendix Studio Pro 10.23.0.

8. Open the affected page and select/click the affected Dynamic Text widget.

Expected behavior

mxcli should do one of the following:

1. Correctly persist the attribute binding / template parameter binding for DYNAMICTEXT inside LISTVIEW.

   For example, if the input is:

   DYNAMICTEXT txtFirstName (
     Attribute: Firstname
   )
   

   then the generated Mendix model should contain a valid Dynamic Text value bound to Firstname.

2. Or, if this syntax/context is not supported yet, mxcli check or mxcli exec should reject it with a clear validation error.

mxcli should not write a partial text template containing {1} without the corresponding parameter binding.

Actual behavior

mxcli accepts the model and reports success.

However, the generated/persisted model appears to drop the actual attribute/template parameter binding and keeps only the text template placeholder:

Content: '{1}'

without the corresponding parameter binding.

This creates an invalid/orphaned template parameter state. Studio Pro then throws a null reference error when opening/selecting the affected widget.

Observed Studio Pro error:

System.NullReferenceException
at ClientTemplateFormPart.CollectControls

Impact

This is high impact because mxcli silently writes a model state that Studio Pro cannot handle correctly.

The failure is difficult to diagnose because:

• mxcli check passes or does not report the missing binding.
• mxcli exec reports success.
• The error only appears later in Studio Pro.
• The model looks superficially valid because Content: '{1}' is still present.
• Studio Pro appears to cache the broken model state until fully closed and reopened.

Workaround

Replacing affected DYNAMICTEXT widgets with plain static text avoids the crash:

DYNAMICTEXT txtFirstName (
  Content: 'Employee Record'
)

After replacing the affected widgets with plain static Content: values and fully closing/reopening Studio Pro, the NullReferenceException no longer occurs.

The downside is that list items show placeholder/static text instead of data-bound values, so the bindings have to be restored manually in Studio Pro's page editor.

Related issue

This may be related to the same class of issue as #547, where template parameters were silently dropped during round-trip. This report concerns DYNAMICTEXT inside LISTVIEW.

Suggested acceptance criteria

• DYNAMICTEXT inside LISTVIEW round-trips losslessly when using attribute/template parameter bindings.
• Content: '{1}' is never persisted without the corresponding parameter binding.
• mxcli check detects orphaned template placeholders such as {1} with no parameter binding.
• If Attribute: or ContentParams: is unsupported for this widget/context, mxcli rejects it with a clear validation error instead of writing a broken model.
• Opening/selecting the affected widget in Studio Pro 10.23.0 no longer causes System.NullReferenceException.

Additional notes

I am reporting this as a user of mxcli through OpenCode, not as someone who has inspected the mxcli internals. The observed behavior strongly suggests that the binding is dropped during mxcli validation/persistence/round-trip, but I may not have identified the exact internal root cause.

[github-actions]

Issue Triage

Summary:
The issue reports that mxcli silently drops attribute/template‑parameter bindings for DYNAMICTEXT widgets inside a LISTVIEW, leaving orphaned {1} placeholders that cause a System.NullReferenceException in Mendix Studio Pro.

Checklist for bug‑report completeness

Required info	Present?	Details
mxcli version	✅	nightly (2026-06-07T12:42:15Z)
Mendix version	✅	10.23.0
Scenario (what the user was trying to do)	✅	Creating/modifying a page with a LISTVIEW containing a DYNAMICTEXT bound to an attribute or using ContentParams; running mxcli check and mxcli exec.
Expected output	✅	Binding persisted correctly or mxcli should reject with a clear validation error.
Experienced output	✅	mxcli reports success but the binding is missing; Studio Pro throws NullReferenceException when the widget is selected.
AI bug report (mxcli diag --bundle or session log)	❌	Not provided.

Missing information
To help investigate the root cause, could you please provide the output of mxcli diag --bundle (or at least the relevant session log) from the run that produced the broken model? This will give us insight into mxcli’s internal validation/persistence steps.

Thank you for the detailed report! Once we have the diagnostic bundle we can look into why the binding is being dropped.

---

Automated triage via OpenRouter — workflow source

[kovacoj]

Thanks for the triage.

I reproduced the issue and captured a fresh diagnostic bundle.

Reproduction:

Input script (repro_listview_dynamictext.mdl):

CREATE PAGE TaskManager.TaskList
  (
    Title: 'Task List',
    Layout: Atlas_Core.Atlas_Default
  )
  {
    LISTVIEW lvTasks (DataSource: DATABASE TaskManager.Task) {
      DYNAMICTEXT txtTitle (
        Attribute: Title
      )
    }
  }

mxcli reported success, but describing the page afterwards shows:

dynamictext txtTitle (Content: '{1}')

The Attribute: Title binding was silently dropped, leaving an orphaned {1} placeholder with no corresponding parameter binding.

Diagnostic bundle:

Generated by running mxcli diag --bundle from the project root after the write. The bundle log confirms the CreatePageStmtV3 for TaskManager.TaskList at 09:09:13 followed by describe PAGE TaskManager.TaskList.

Environment confirmed:

• Mendix Studio Pro: 10.23.0
• mxcli: nightly (2026-06-07T12:42:15Z)
• Context: mxcli used through OpenCode

mxcli-diag-20260608-090919.tar.gz

[ako]

Fixed on the issues branch (commit 61d65ed), pending merge to main.

Root cause — not a round-trip/persistence corruption as suspected, but a missing read: buildDynamicTextV3 handled Content/ContentParams but never read the Attribute: property, so DYNAMICTEXT (Attribute: Title) discarded the binding and defaulted the template to an orphaned {1}. (The ContentParams: [{1} = X] form already worked.) The orphan is what fails MxBuild with CE0720 and throws the Studio Pro NullReferenceException; mxcli check had no detection, matching the 'check passes, Studio Pro crashes' symptom.

Fix (both acceptance paths):

1. Persist — Attribute: X is now bound as a single template parameter via the same resolver the working ContentParams form uses (non-String attributes get toString()). Shared builder → both engines.
2. Detect — new MDL-WIDGET04 mxcli check rule flags a dynamictext whose Content references {N} with fewer than N bound parameters, so an orphaned placeholder is caught at check time instead of MxBuild / the editor.

Verified on Mendix 11.11.0: Attribute: Title → ContentParams: [{1} = Title]; an Integer attribute → [{1} = toString($currentObject/Count)]; mx check = 0 errors; DESCRIBE round-trips. The orphaned Content: '{1}' form is now rejected by mxcli check (was silently passing).

Covered by validation + builder unit tests, a positive bug-test (650-dynamictext-attribute-binding.mdl) and a negative .fail.mdl for MDL-WIDGET04.

Note: Content: <bareName> (e.g. Content: Title) remains static literal text per existing documented behavior — use Attribute: or ContentParams: to bind.