LT-21402: Part 3 - Move MasterRefresh to Pub/Sub (Insert/Delete) - #1039
LT-21402: Part 3 - Move MasterRefresh to Pub/Sub (Insert/Delete)#1039mark-sil wants to merge 1 commit into
Conversation
These two senders (InsertEntryDlgListener.DialogInsertItemInVector and RecordClerk.OnDeleteRecord) both update the cache directly (UOW + PropChanged), so when an XHTML document view is active, the Mediator's High-priority stop-when-handled intercept correctly satisfied the refresh with a fast content-only reload; the full master refresh was only needed in the other tools. Pub/Sub has no stop-when-handled, so the intercept is replaced with a two-stage refresh request. - New event RefreshCurrentView. The sender publishes it (window-scoped) with a ReturnObject; a subscriber that can satisfy the request by regenerating its own content sets ReturnValue. If no subscriber claims the request, the sender publishes MasterRefresh instead. - XhtmlDocView subscribes while it exists (Init/Dispose), i.e. exactly while its tool is the active content control - the subscription lifetime does the routing that colleague priority used to do. - XhtmlRecordDocView (the Lexicon Edit preview pane) deliberately does NOT subscribe: in Lexicon Edit these commands do the full refresh today, and that is preserved. Behavior is unchanged: content-only reload when a Dictionary, Reversal Indexes, or Classified Dictionary document view is active; full master refresh everywhere else. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #1039 +/- ##
==========================================
- Coverage 33.05% 33.04% -0.01%
==========================================
Files 1202 1202
Lines 278342 278365 +23
Branches 37191 37195 +4
==========================================
Hits 91994 91994
- Misses 158493 158511 +18
- Partials 27855 27860 +5
🚀 New features to boost your workflow:
|
| Debug.Assert(false, "Received unexpected object type."); | ||
| return; | ||
| } | ||
| // Return if already handled by another Subscriber. |
There was a problem hiding this comment.
Would there ever be two current views that need to handle this (e.g. multiple panes or windows)?
There was a problem hiding this comment.
Good question — no, by design, on both counts:
Multiple windows: both ends are window-scoped (m_propertyTable.GetWindow()), so a publish from window A's clerk only reaches window A's subscribers. A second window showing the Dictionary view never sees the request (matching the old per-window Mediator behavior).
Multiple panes in one window: XhtmlDocView only exists as the main content control of the three document tools (Dictionary, Reversal Indexes, Classified Dictionary), and a window has exactly one main content control at a time (this is similar to what the Mediator relied on) — the view is disposed (and unsubscribed) on tool switch. The one view that can coexist alongside another content control, XhtmlRecordDocView (the Lexicon Edit preview pane), deliberately doesn't subscribe: in Lexicon Edit these commands should do the full refresh, and the preview updates via PropChanged. So at most one subscriber can receive any given request today.
3 participants
Summary
Converts the last two synchronous MasterRefresh senders —
InsertEntryDlgListener.DialogInsertItemInVector(Insert Entry) andRecordClerk.OnDeleteRecord(Delete Record) — completing the synchronous half of theLT-21402 migration (follows #1033 and #1038).
These two were deliberately excluded from Part 1: both commands update the cache directly
(UOW + PropChanged), so when an XHTML document view is active, the Mediator's
High-priority stop-when-handled intercept correctly satisfied the refresh with a fast
content-only reload; the full master refresh was only needed in the other tools.
Converting them to a plain
Publish(MasterRefresh)would have turned that fast, correctreload into a needless full refresh.
Design: two-stage refresh request
Pub/Sub has no priority or stop-when-handled, so the intercept is replaced with a
two-stage request, using the same
ReturnObjectidiom as theDialogInsertItemInVectorconversions (see
RecordClerk.OnInsertItemInVector):RefreshCurrentView. The sender publishes it (window-scoped) with aReturnObject; a subscriber that can satisfy the request by regenerating its owncontent sets
ReturnValue. If no subscriber claims the request, the sender publishesMasterRefreshinstead.XhtmlDocViewsubscribes while it exists (Init/Dispose) — i.e. exactly while its toolis the active content control — so the subscription lifetime does the routing that
colleague priority used to do.
XhtmlRecordDocView(the Lexicon Edit preview pane) deliberately does notsubscribe: in Lexicon Edit these commands do the full refresh today, and that is
preserved.
Behavior is unchanged: content-only reload when a Dictionary, Reversal Indexes, or
Classified Dictionary document view is active; full master refresh everywhere else.
The
JumpToRecordsend next to the Insert Entry site stays on the Mediator; that messageis a separate conversion.
Remaining MasterRefresh work (future PRs)
Still on the Mediator: the F5/CmdRefresh menu command (which can reuse this two-stage
pattern when converted), four deferred
BroadcastMessagesenders, and onePostMessagesender — each needs per-site timing analysis before conversion.
Testing
manual tests).
FwXWindow.OnMasterRefreshnot invoked, jump-to-new-entry intact) and from LexiconEdit (full refresh, unchanged); reversal document view delete; multi-window scoping
(single dispatch, focus retained).
🤖 Generated with Claude Code
This change is