ich "denke" das du ein altes Cl*pper Verhalten nachbilden willst ... die DBF ist "immer verfügbar".
sicherlich könntest du ein VALID jedes mal ausführen ... aber ein User kann ja, per Maus, anfangen wo er will.
Werner_Bayern hat geschrieben:Macht der killInputFocus und geht wieder zurück in das Feld. Da ist also noch nicht viel passiert, weil das das 1. Feld ist, das ggf. geändert wird.
dein Beispiel mit einer ID ( Artikel ) als 1st Eingabe bei "Neu" ist wie unter Cl*pper gewohnt.
Problem (für den User) : er weiss nicht was "hinter" der ID steckt ! Ich präsentiere dann FOUND() in einem Browse statt MsgBox()
---
wenn 10 neue Artikel rein gekommen sind und es 2 Sachbearbeiter gibt kann es passieren das beide einen Artikel mit unterschiedlicher ID erfassen wenn die "Kommunikation" nicht stimmt.
nun kann man aber mit so wenig Informationen keine "Aussage" machen ... erst wenn weitere Felder ausgefüllt wurden -> "save".
erst hier fange ich mit dem validieren an.
Das anspringen von einem bemängelten Feld ist gut aber es sollten dann gleich alle Felder markiert werden.
ich schalte dann alle OK Felder auf
was auch optisch sichtbar wird.
Werner_Bayern hat geschrieben:Gutes Beispiel, ist mir klar. Viel flexibler, aber auch viel komplizierter ohne rlock: Was wenn einer die Straße und der andere den Ort ändert. Ist jetzt vielleicht an den Haaren herbeigezogen, aber theoretisch zieht der Kunde von A nach B um, die Straße heisst aber immer noch Alleestraße. Der andere Nutzer ändert die Straße, weil er doch eigentlich in der Seitenstraße der Alleestraße (gewohnt hatte) wohnt.
ich schicke beim "save" eine Email im internen Netzwerk über eine neue Artikel Nummer. die bekommt auch ein Mitarbeiter der im Urlaub war !
die User beschweren sich zwar weil "einzeln" ... aber jeder soll alle Informationen bekommen um auf dem aktuellen Stand zu sein.
Werner_Bayern hat geschrieben:eine Transaktion taucht nach meinem Verständnis für andere Benutzer im Netzwerk erst auf, wenn sie erfolgreich abgeschlossen wurde.
bei DBF Dateien kann man im Datalink die Daten direkt, mit RLock(), in die DBF zurück schreiben. Damit wären die "sofort" im Netzwerk sichtbar.
wenn du das VALID nun mit KillInputFocus simulieren willst wären die Daten nach der Transaktion, welches eine Sperre ausführt, ebenfalls sichtbar.
beide Methoden würden aber einen beträchtlichen Netzwerk Verkehr erzeugen ... und damit auch evtl. Fehler ( zu kleine Daten Pakete / Cache )