Inoffizielles deutsches Xbase-Forum

Hallo,

hat schon jemand mit dbRegisterClient() Erfahrungen gesammelt ?

Das Beispiel mit einer Neuimplementation von @ GET ist ja wieder zum schreien ...

Ich würde es natürlich mit XbpSLE einsetzen.

Hallo Hubert,

ja, ich setze das in einem meiner Projekte ein. Natürlich GUI pur, wie immer

Allerdings nutze ich bei weitem nicht alles, was die Funktion anbietet. Bei mir ist das hauptsächlich die Aktualisierung von SLE im Verbund mit einem Browse. Und SLE zu anderen Tabpages mit dem Browse und weiteren SLE.

Jan

Hi,

ich bin gerade mal wieder darauf gestossen in der Anleitung, bzw. im Beispiel MDIDEMO. Was macht man damit überhaupt, irgendwie verstehe ich nur Bahnhof.

ich bin mal wieder hier im Forum darauf gestossen. Können wir das Thema nochmals aufwärmen und ein wenig Licht ins Dunkel bringen? Ich habe immer noch nicht so richtig den Einsatzsinn und -zweck verstanden.

Da vermutlich ich den aktuellen Anlass dazu gegeben habe zitiere ich frei aus der 1,9er Hilfe.
Man sollte diese Methode verwenden wenn der Anwender in seiner Applikation mehrere Fenster auf die gleiche Datenquelle, also Tabelle, öffnen kann.
Ändert dieser in einem Fenster Daten erzeugt nach eine DbRegisterClient die DBE ein Notify sodaß alle geöffneten Fenster die auf dieselbe Tabelle zugreifen ein REQUERY bzw. einen REFRESH auslösen können und die Änderungen in allen Fenstern sichtbar werden ...

alles klar, jetzt habe ich es verstanden.
Wobei da natürlich das Problem mit den Threads dann wieder aufkommt (wie schon erwähnt hier im Forum). Wer also die einzelnen Menues in verschiedenen Threads aufruft muß dann was stricken, damit man die anderen Workareas sieht.

Es gibt ja grundsätzlich wie unter Clipper die Möglichkeit, dass du bei einem Fenster die Buttons zum Skippen mit Funktionen hinterlegst und das dann so aussieht:

Button Anfang => dbGoTop(), alle controls aufrufen und z.B. aEditControls:setdata() auszuführen.
Button Ende => dbGoBottom(), alle controls aufrufen und z.B. aEditControls:setdata() auszuführen.
...
Button Edit und Button Save, jeweils im Programm dann auf der Seite disable() was grad nicht erlaubt ist und hoffen, dass nicht eine Routine im Hintergrund auf der Datei ein dbskip() macht etc.

ODER

Man registriert alle Controls in ihrer Workarea (es können verschiedene Dateien pro Fenster sein) und egal warum ein dbSkip() ausgeführt wird,
würde die notify() methode aufgerufen und im einfachsten Fall die Daten neu ins Control geladen werden.
Im Beispiel wird mal wieder ein schönes ... DBGET() ... also kein Control im eigentlichen Sinne genutzt. Nicht wirklich erhellend.

Im Grunde geht es darum, die Controls selbst wissen zu lassen wo sie die Daten herbekommen und in der Oberfläche nicht jedesmal den gleichen Code schreiben zu müssen ...
??? darf ich jetzt skippen
??? muss ich vorher speichern, soll ich fragen oder ...

Das könnte man alles zentral in einer Routine regeln, die per do case die einzelnen Stadien abarbeitet und gezielt reagiert.

Wer also die einzelnen Menues in verschiedenen Threads aufruft muß dann was stricken, damit man die anderen Workareas sieht.

man soll das ja gerade nicht machen, jeder Thread nutzt seine offene Workarea und man hat keine Probleme

Ein Beispiel für Notify findest du bei den Beispielen:

???\XPPW32\source\samples\apps\mdidemo\datadlg.prg

man soll das ja gerade nicht machen, jeder Thread nutzt seine offene Workarea und man hat keine Probleme

was meinst Du damit? Das verstehe ich nicht.

Manfred hat geschrieben: ↑Mi, 06. Dez 2017 12:28

man soll das ja gerade nicht machen, jeder Thread nutzt seine offene Workarea und man hat keine Probleme

was meinst Du damit? Das verstehe ich nicht.

Nun man soll nicht versuchen auf Workareas anderer Threads zuzugreifen. Das ist nur bei sehr speziellen (mir jetzt entfallenen) Aufgabenstellungen nötig.
Also jeder Thread soll sich seine Dateien selbst öffnen, auch wenn dadurch eine DBF in 2 Threads offen ist.

OK, dann habe ich es doch verstanden. Aber dann ist ja DbRegisterClient() uninteressant in selchen Modellen!?

Hallo,
ich nutze es z.B. um die DBF Dateien zu synchronisieren, ist eine geniale Funktion. Damit kann ich z.B. im ERP System den Artikelstamm in verschiedenen Mandanten synchronisieren. Für einen andere Anwendung synchronisiere ich DBFs mit SQL Tabellen, habe damit sofort gespiegelte Daten auf SQL für Schnittstellen und andere Anwendungen. Und es funktioniert sehr zuverlässig.
Grüße
Rudolf

SCATTER() und GATHER() arbeiten auch zuverlässig aber trotzdem bevorzuge ich die "volle" Schreibweise die ich noch Jahre später identifizieren kann.

---

was Thread angeht, welche ihre eigene Workspace haben, muss man mit Events arbeiten. ---

das Problem des "update" von anderen XbPart in einem Fenster hat man oft mit einem Browse.
nun gibt es 2 Möglichkeiten :

a.) die "alte" wenn ein Browse "stable" ist
b.) per Event mit DbRegisterClient()

man sollte aber IMHO nicht "beide" Methoden gleichzeitig verwenden

während a.) immer nur "1 Tastendruck" verarbeiten kann "könnte" mit b.) eine Reihe von Events kommen.

---

IMHO funktioniert DbRegisterClient() nur innerhalb "einer" Xbase++ App.
weder eine weitere Instanze lokal oder im Netzwerk bekommt "jemand" etwas von dem Xbase++ "UserDef" Event mit

---

ich schreibe meinen xBase Source Code gerne so das ich ihn mit verschiedenen Compilern gebrauchen kann.
Xbase++ "Erfindungen" sind in solchen Fällen wie eine 3-PP Lib wo man kein Zugriff hat