AyCode.Blazor/AyCode.Blazor.Components/docs/MGGRID/MGGRID_ISSUES.md

4.0 KiB

MGGRID — Known Issues

For planned/actionable work see MGGRID_TODO.md. In-code TODOs are recorded as TODO entries (ACBLAZOR-GRID-T-*) there, since they describe unfinished work rather than confirmed broken behaviour.

ACBLAZOR-GRID-I-N7K2: InfoPanel.SetEditMode crashes the WASM renderer when DxGrid produces no edit model

Severity: Major (unhandled exception killed the renderer) · Status: Closed (2026-07-12) · Area: Components/Grids/MgGridBase.csOnCustomizeEditModel

Description

Clicking the toolbar Edit button could crash the entire WebAssembly renderer with System.ArgumentNullException: editModel thrown by MgGridInfoPanel.SetEditMode. Observed on a ProductDto grid right after a datasource reload (OnDataSourceLoaded → immediate Edit click): DevExpress StartEditRowAsync raised CustomizeEditModel with e.EditModel == null (stale FocusedRowVisibleIndex → null data item), and OnCustomizeEditModel passed the null straight to SetEditMode, whose ArgumentNullException.ThrowIfNull escalated to an unhandled rendering exception.

Root cause

MgGridBase.OnCustomizeEditModel captured (e.EditModel as TDataItem)! (null-forgiving cast) with no null check, and on the Edit path (IsNew == false) nothing validated it before InfoPanelInstance.SetEditMode. The local was also captured BEFORE the OnGridCustomizeEditModel consumer callback — so a consumer-created edit model (the official DevExpress pattern for types without a parameterless constructor) never reached the InfoPanel either.

Resolution (2026-07-12)

OnCustomizeEditModel hardened: null-tolerant cast, guarded IsNew branch, the edit model is re-read AFTER the consumer callback, and when it is still null the InfoPanel stays in view mode with a Logger.Warning ([GridName] CustomizeEditModel produced no edit model...) instead of crashing.

Known workaround

None needed after the fix.

None.

ACBLAZOR-GRID-I-K5R3: InfoPanel built-in toolbar edit tools are not configurable

Severity: Minor (UX / consistency gap; can re-open a crash path on listing-only grids) · Status: Open · Area: Components/Grids/MgGridInfoPanel.razor (built-in toolbar) + MgGridToolbarTemplate

Description

MgGridInfoPanel renders its built-in toolbar with hardcoded defaults (MgGridInfoPanel.razor:20: <MgGridToolbarTemplate Grid="_currentGrid" OnlyGridEditTools="true" ShowOnlyIcon="true" />), so EnableNew / EnableEdit are always true there. When a consumer disables New/Edit on its own master toolbar (e.g. a listing-only grid such as a product grid whose data is managed in an external admin and has no Add/Update SignalR tags), the InfoPanel toolbar still offers + and edit — the edit flow can be started through a side door the consumer cannot close.

Root cause

The panel's toolbar instance is not parameterizable from the outside, and there is no grid-level edit-enable flag the toolbar could consult — the Enable* flags live only on individual MgGridToolbarTemplate instances.

Known workaround

None from the consumer side (the panel toolbar cannot be reached). Master-toolbar EnableNew="false" EnableEdit="false" covers the primary path only.

Proposed fix

Grid-level EditItemsEnabled parameter on MgGridBase / IMgGridBase (default true); MgGridToolbarTemplate computes effective enablement as own Enable* && Grid.EditItemsEnabled, so both the master and the built-in InfoPanel toolbar respect a single consumer declaration.

None yet — becomes a TODO when scheduled.

Issue entry template

## ACBLAZOR-GRID-I-XXXX: Short title

**Severity:** Trivial / Low / Minor / Major · **Status:** Open / Documented / Mitigated · **Area:** <subsystem>

### Description
What breaks, and under what conditions.

### Root cause
Why it happens (code location + design mismatch).

### Known workaround
Steps a consumer can take until fixed.

### Related TODO
`MGGRID_TODO.md#acblazor-grid-t-XXXX` (if applicable).