[thejambi]

Typing into the shown entry from another view, such as a column of the Entries list, no longer makes the new (Avalonia) detail view lag. It used to rebuild the whole detail view on every keystroke; now the first change shows at once and the rest of the burst updates the view once, a quarter-second after typing stops. A single edit, Undo or Redo still shows immediately.

In Notebook, undoing an edit to a record's Text field now redraws the view instead of leaving the old text until F5, and so does a change to the top-level record while one of its subrecords is selected.

The rest of LT-22692 already behaves as the ticket asks: Undo and Redo update the view in place on the same record and keep the scroll position, F5 rebuilds on the same record, and F5 while typing commits the typed text. F5 and Styles OK reach the Avalonia view through #1236, already merged.

Reviewer notes

Builds on #1236 (LT-22811), merged. #1236 added RecordEditView.RefreshDisplay, which makes F5 and Styles OK recompose the Avalonia view (the ticket's F5 step), with tests. This branch has been rebased onto main since, so its diff is the LT-22692 work only.

Root cause. AvaloniaDetailRefreshController.PropChanged sent every relevant change from outside the view straight to a full recompose on the next UI tick. Its queue only merged changes raised in the same call stack, and each keystroke typed in another view is its own unit of work, so each one rebuilt the whole detail view. The WinForms DataTree updates the affected slice in place, which is why it does not lag.

Root cause, Notebook. RecordEditView.IsChangeWithinEntry counted a change only when its owner chain reached Clerk.CurrentObject. Notebook's Text row (obj field="Text" in NotebookParts.xml) shows a Text the record references, not owns, so a paragraph's owner chain (StTxtPara, StText, Text) never reaches the record. And Notebook shows the top-level record while a subrecord is current, so a change to the top-level record's own fields was judged against the subrecord and missed.

Deliberate rules.

• The first outside change of a burst rebuilds at once; later ones wait until no further change has arrived for 250 ms and rebuild once. 250 ms is a judgement call, not a measured value: long enough to batch typing, short enough to feel immediate after a pause.
• The wait is supplied by the host through a new optional deferUntilQuiet argument; without it the controller refreshes every change as before. RecordEditView supplies a restartable WinForms timer, created on first use, disposed with the controller, and always run on the UI thread (a change raised elsewhere re-posts the wait there).
• A rebuild the view asks for itself (after its own commit, F5, Styles OK) is never held, and it clears any change still waiting, since it reads current state.
• An open edit still holds every rebuild until it completes, including one that comes due when a burst goes quiet.
• A change held for one entry does not rebuild the view once the user has moved to another entry; showing that entry already read current state. A change to the newly shown entry during the same burst still rebuilds.
• A change is relevant when its owner chain reaches the record the view shows or any object one of its rows is bound to (DetailField.ObjectHvo). Both are captured when the view shows a record and cleared when it shows a message, clears for a missing record or a suspended load, or is torn down; the shown record is not resolved again on each change notification, so a notification raised mid-delete cannot walk off a deleted object's owner. While no record is remembered as shown, relevance falls back to the clerk's current record, so a record the clerk selects without a show still refreshes on an outside change.
• Moving to another record forgets the shown record before the open edit settles, so that commit is judged against the record about to be shown and does not rebuild it a second time.

Tests. DetailEditGuardAndSchedulingTests gains six controller tests, each driving real LCModel units of work (one per keystroke): a burst rebuilds once at the start and once when quiet; a single change rebuilds once; a rebuild the view asks for mid-burst covers the waiting change; a burst that goes quiet during an open edit holds the rebuild; a burst that goes quiet after moving to another entry does not rebuild it; a change to the newly shown entry during a burst still rebuilds. For Notebook, two relevance tests on a real notebook record with a subrecord and a referenced Text (a paragraph counts only through the Text row's bound object; the top-level record's change counts against the shown record), and ShowingARecord_RemembersItAndItsRowObjects_ForRefreshRelevance checks the wiring through a real Lexicon Edit show. Through the live view in DetailObjectCommandExecutionTests: leaving an entry with an edit open builds the next entry once (it fails with a second build when the forgetting is removed); with no record remembered as shown, an outside change to the clerk's current entry brings it up; and the quiet wait runs only the last deferred action, once. xWorksTests: 1941 of 1943 passed (2 skipped).

Manual tests (done). On Sena 3 with the new UI, the ticket's acceptance steps using the toolbar Undo and Redo: an edit commits on clicking away; Undo and Redo revert and restore in place, keeping the scroll position and the record; F5 rebuilds on the same record with edits intact; F5 while typing in Gloss commits the typed text; Undo while typing first saves the text as its own step. Typing several characters into the entry's Gloss in the Entries list no longer lags, and the detail view follows. The dictionary preview at the top of the pane turns gray while it refreshes in the WinForms UI too. In Notebook Edit, undoing an edit to a record's Text redraws the view without F5, and so does a change to the top-level record's fields while a subrecord is selected.

Out of scope. Ctrl+Z and Ctrl+Y inside Avalonia fields are trapped by the text boxes' own undo; that is LT-22820. The toolbar Undo and Redo tooltips show the generic ContextHelp.xml text in both UIs; the specific label is on the Edit menu. The Entries list scrolling the selected last row to second-to-last after an edit is the browse view's own behaviour. A change to an object a row only names, such as renaming a semantic domain a sense lists, still does not redraw the view, since no row is bound to that object.

🤖 Generated with Claude Code

---

This change is 

[github-actions]

NUnit Tests

    1 files  ± 0      1 suites  ±0   8m 47s ⏱️ - 6m 11s
7 254 tests +13  7 169 ✅ +13  85 💤 ±0  0 ❌ ±0 
7 263 runs  +13  7 178 ✅ +13  85 💤 ±0  0 ❌ ±0 

Results for commit c8bf2ff. ± Comparison against base commit facc384.

♻️ This comment has been updated with latest results.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 76.59574% with 22 lines in your changes missing coverage. Please review.
✅ Project coverage is 40.84%. Comparing base (facc384) to head (c8bf2ff).

Files with missing lines	Patch %	Lines
...xWorks/Avalonia/Hosting/RecordEditView.Avalonia.cs	70.31%	11 Missing and 8 partials ⚠️
...valonia/Hosting/AvaloniaDetailRefreshController.cs	89.28%	0 Missing and 3 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1238      +/-   ##
==========================================
+ Coverage   40.83%   40.84%   +0.01%     
==========================================
  Files        1573     1573              
  Lines      357160   357249      +89     
  Branches    41812    41828      +16     
==========================================
+ Hits       145835   145911      +76     
- Misses     182019   182026       +7     
- Partials    29306    29312       +6     

Files with missing lines	Coverage Δ
Src/xWorks/RecordEditView.cs	62.19% <100.00%> (+0.16%)	⬆️
...valonia/Hosting/AvaloniaDetailRefreshController.cs	83.72% <89.28%> (+7.25%)	⬆️
...xWorks/Avalonia/Hosting/RecordEditView.Avalonia.cs	64.29% <70.31%> (+0.57%)	⬆️

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mark-sil]

Notebook still builds twice when you leave a subrecord with an edit open

ForgetShownRecordIfLeaving compares the resolved record, so moving between two subrecords of the same top-level record (e.g. toolbar Next/Previous, which steps through AllRecords without taking focus from the field) keeps m_shownRecord. The settle-commit in ShowRecordOnIdle then changes a field owned by that top-level record, IsChangeWithinEntry counts it, and the controller queues a refresh that rebuilds the view a second time after the navigation's own show.

On main this didn't happen: relevance was checked against Clerk.CurrentObject, which is already the new subrecord at settle time, and the left subrecord's change doesn't reach it. So it's the same double build c58b3a1 fixed for entries, still open for Notebook's same-root case.

One option: forget the shown record whenever the clerk's current object differs from the one it was shown for, not only when the resolved root differs. A Notebook version of LeavingARecordWithAnOpenEdit_BuildsTheNextRecordOnce, moving between two subrecords of one record, would cover it.

[thejambi]

Fixed!

[mark-sil]

LGTM