From 90e500333a57b89682a23a057e054e6a6c8f37ee Mon Sep 17 00:00:00 2001 From: Developer01 Date: Tue, 11 Aug 2026 15:32:11 +0200 Subject: [PATCH] Fix: Reset_Current() leerte das Grid vor dem Hit-Test in Item_Scope MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Root Cause des ursprünglich gemeldeten Bugs gefunden: Reset_Current() wurde als allererste Aktion in Item_Scope aufgerufen, NOCH BEVOR die angeklickte Zeile ermittelt wird. Reset_Current() ruft DT_CURR_WF_ITEMS.Clear() auf - und DT_CURR_WF_ITEMS ist über bindsourcegrid direkt die Datenquelle von GridControlWorkflows/GridViewWorkflows (siehe Bindings z.B. frmMain.vb:1445-1446). Das Clear() leert also synchron genau das Grid, in dem gerade doppelgeklickt wurde, bevor CalcHitInfo/FocusedRowHandle überhaupt ausgewertet werden - beide sind danach zwangsläufig InvalidRowHandle, da schlicht keine Zeilen mehr existieren. Das erklärt auch die im Log beobachteten doppelten SaveGridLayout-Aufrufe (Grid reagiert auf die Leerung) und das spätere "has no children" beim Rendern der Gruppenzeilen. Der zuvor implementierte FocusedRowHandle-Fallback in Item_Scope war dadurch wirkungslos, da auch FocusedRowHandle zu diesem Zeitpunkt ungültig ist. Fix: Den verfrühten Reset_Current()-Aufruf entfernt. Die davon zurückgesetzten Felder werden im weiteren Verlauf ohnehin frisch gesetzt (CURRENT_JUMP_DOC_GUID erneut bei Zeile ~2735, CURRENT_ProfilGUID durch Load_Profil_from_Grid selbst). Der zweite, bestehende Reset_Current()-Aufruf im GRUPPE-Zweig (nach erfolgreicher Zeilenauflösung, vor Load_Profil_from_Grid) bleibt unverändert bestehen und deckt den eigentlich benötigten Reset weiterhin ab. Enthält zusätzlich eine Diagnose-Logzeile in GridViewWorkflows_MouseDown, die beim Testen ergänzt wurde. Co-Authored-By: Claude Sonnet 5 --- app/TaskFlow/frmMain.vb | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/app/TaskFlow/frmMain.vb b/app/TaskFlow/frmMain.vb index 3833748..d58d3bb 100644 --- a/app/TaskFlow/frmMain.vb +++ b/app/TaskFlow/frmMain.vb @@ -2522,7 +2522,13 @@ Public Class frmMain Try LOGGER.Info("Starting Profile Loading") - Reset_Current() + ' WICHTIG: Reset_Current() NICHT hier aufrufen! DT_CURR_WF_ITEMS ist über + ' bindsourcegrid die Datenquelle von GridControlWorkflows/GridViewWorkflows - + ' Reset_Current() leert sie (DT_CURR_WF_ITEMS.Clear()), was das Grid, in dem + ' gerade geklickt wurde, synchron auf 0 Zeilen setzt, BEVOR der Hit-Test unten + ' überhaupt läuft. Das macht effectiveRowHandle/FocusedRowHandle-Fallback + ' zwangsläufig ungültig. Reset_Current() wird stattdessen weiter unten + ' (GRUPPE-Zweig) erst NACH erfolgreicher Zeilenauflösung aufgerufen. ' ========== UI-VORBEREITUNG ========== Me.UseWaitCursor = True @@ -3545,6 +3551,7 @@ Public Class frmMain Dim view As GridView = sender Dim hi As GridHitInfo = view.CalcHitInfo(e.Location) Dim groupRowButtonClicked = (hi.HitTest = GridHitTest.RowGroupButton) + LOGGER.Debug($"MouseDown: RowHandle=[{hi.RowHandle}], HitTest=[{hi.HitTest}], InGroupRow=[{hi.InGroupRow}], InDataRow=[{hi.InDataRow}], GroupRowButtonClicked=[{groupRowButtonClicked}]") ' ===== UNGÜLTIGE CLICKS ABFANGEN ===== ' Anders als in Item_Scope ist hier KEIN FocusedRowHandle-Fallback sinnvoll: ' e.Location ist immer aktuell (kein Caching-Problem), und InvalidRowHandle ist