90e500333a
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 <noreply@anthropic.com>