Phänomen in XbpBrowse

[Jan]

Gerade hat ein Mitarbeiter meines Kunden mir etwas interessantes gezeigt. In dem Programm gibt es einen XbpBrowse und diverse disabelte XBParts. In :itemSelected() steht drin, das dann der betreffende Datensatz mit DbRLock() gesperrt wird, die anderen XBParts werden enabled, und in verschiedenen XBParts die einzelnen Datenbankwerte bearbeitet werden können. Klickt der Mitarbeiter nun nach dem Bearbeiten wieder auf den Browse, werden wieder alle anderen XBParts disabled, und der Fokus geht auf den Browse. So weit so gut.

Klickt der Mitarbeiter aber beim Zurückspringen nicht auf einen Satz im Browse sondern auf den Schieber vertikalen Laufleiste des Browses, dann kommt der Laufzeitfehler "Datei oder Datensatz muß für Operation gesperrt sein", Auslöser ist der vorher aktive XBPart (ein XbpMle). Das passiert auch nur beim Klick auf den Schieber, ein Klick auf die Laufleiste selber ist ohne negative Nebenwirkungen.

Kann mir jemand sagen, woher das kommt?

Jan

[AUGE_OHR]

hi,

reden wir hier vom "vertikalen" Scrollbar ? hat das XbpMLE einen Datalink zum Browse ?

mit dem "Schieber" wird ja ein XBPSB_SLIDERTRACK Event ausgelöst der durch XBPSB_ENDTRACK beendet wird.
Damit bewegst du den Record Pointer und du verlierst den "Lock".

p.s. ich würde einen "normalen" Pushbutton zum "saven" benutzen und den "disable" Kram in ein VALID packen.

[Jan]

Hallo Jimmy,

nein, der XbpMle wird über den oBrowse:stableForce synchronisiert.

Und ja, wie ich schrieb, der vertikale.

Und nein, es ist nicht die Satzbewegung. Denn ich kann auf egal welchen Satz im Browse klicken oder auf egal welchen Bereich der Scrollbar - kein Problem. Nur der Slider selber macht Zicken

Jan

[Tom]

Ich denke, Du wirst bei dieser Konstruktion den Callback "Scroll" des Scrollbalkens überladen müssen - und ihn damit dazu bringen, nichts zu tun, wenn gerade ein Datensatz bearbeitet wird und deshalb gesperrt ist und nicht verlassen werden darf. Sonst wird nämlich nach der Navigation durch den Scrollbalken das KillInputFocus für die XbParts ausgelöst, die dann versuchen, ihre Daten in Datensätze zu schreiben, die nicht mehr aktuell sind und erst gesperrt werden müssten, um (falsche!) Daten in sie zu schreiben. Häng doch einfach mal ein bisschen Debugcode in das fragliche MLE und lass Dir zeigen, in welchen Datensatz es schreiben will. Du wirst sehen, dass es der falsche ist.

[Jan]

Hallo Tom,

werd ich mal versuchen. Aber dennoch irritiert mich, das der Fehler nur beim Slider auftritt. Nicht der Rest der Scrollbar, nicht der Datenbereich, nix.

Jan

[AUGE_OHR]

... das der Fehler nur beim Slider auftritt.

was ich dir mit XBPSB_SLIDERTRACK / XBPSB_ENDTRACK versucht habe zu erklären.

wenn du den Slider betätigst "verlierst" du den Focus auf das Browse was in per PDR 5552 "umgekehrt" beschrieben wird. wenn du nun in den Source von XbpBrowse siehst wirst du sehen das dass "self" im ::HandleEvent( xbeBRW_Navigate, ... ) fehlt was den Unterschied ausmacht.

in meinem WMPlayer "nutze" ich nun den Slider per Wheel und kann , per Focus Trick, auch im "Vollbild" Modus in der DBF navigieren um die Informationen für den nächsten Szene "Cut" zu bekommen.

deshalb sage ich ja das man einen "Save" Button haben sollte und das nicht über den o:KillInputFocus Slot "automatisieren" sollte.