Eine dbf gleichzeitig in zwei Browses [Erledigt]

[Jan]

Eine Fortsetzung des Problems mit dem Scope...

Ich habe die dbf mit den Positionen, die abgearbeitet werden sollen. In einem Browse sollen alle die Positionen angezeigt werden, die der angemeldete Mitarbeiter erledigen soll. Zur Info, damit der weiß was da noch alles zu gehört (um z. B. einen Karton in passender Größe für alle Artikel dieses Auftrages zu wählen), sollen in einem zweiten Browse alle anderen Artikel dieses Auftrages angezeigt werden. Das regel ich durch einen Filter, der auf die gescopten Positionen gelegt wird.

Es ist überhaupt kein Problem, die dbf 2x zu öffnen, und bei zweiten einen anderen Alias zu vergeben. Es ist überhaupt kein Problem, diese beiden unterschiedlichen dbf den beiden Browses zuzuordnen. Alle Artikel, die der Mitarbeiter abarbeiten soll, werden auch ganz korrekt angezeigt. Aber in dem anderen Browse werden nicht z. B. 10 weitere Positionen angezeigt, sondern in einer der Anzahl Positionen im ersten Browses entsprechenden Anzahl Zeilen mit immer die gleiche Position. Die zwar in diesen Browse gehört, aber nicht z. B. 3x, nur weil im anderen Browse ganz korrekt 3 abzuarbeitende Positionen angezeigt werden. Und natürlich auch nicht 3x die gleiche Position.

Jan

[Tom]

Hallo, Jan.

Ich habe viele solcher Anwendungsfälle und sie funktionieren alle. Es kann m.E. nur daran liegen, dass Du einen Denk- oder Codefehler hast. Die Browses sind unabhängig voneinander, aber die Datenquellen sind es aus irgendwelchen Gründen nicht. Du machst im "Bearbeiten"-Browse irgendwas, das das andere Browse beeinflusst. Hundertpro. Im einfachsten Fall ist die Filterbedingung falsch bzw. verhält sich dynamisch, obwohl sie statisch sein sollte.

[Jan]

Hallo Tom,

da stimme ich Dir durchaus zu. Was ich habe:

• Gleiche dbf 2x geöfnet, jeweils mit eigenem Alias. Alias ist kontrolliert per Alias(), passt.
• Filter und Scopes auf beide Aliasse passen, werden auch nicht angefasst während der Abarbeitung des Auftrages.
• 2x Browse mit eigenen sprechenden Namen. Werden jeweils komplett eigenständig erzeugt, nur 2 Dinge sind gleich: Das Fontobjekt, und das Array mit den Feldnamen für die verwendeten Spalten.
• Datalinks gehen jeweils auf den korrekten Alias.
• :stableBlock gibt es nur in dem Browse mit den aktuellen Positionen.
• Spalten werden dem korrekten Browse angehängt.
• Im Info-Browse habe ich den Cursor komplett rausgenommen, der würde da nur irritieren. Ändert aber auch nichts am falschen Verhalten.
• Es gibt bei jeder Änderung ein :refreshAll(), das getrennt auf jeden der beiden Browses ausgeführt wird.

Habe ich irgend etwas vergessen, was eine Falle sein könnte?

Code posten wird hier etwas schwierig, weil sich das natürlich in die Länge zieht.

Jan

[Jan]

Ich habe mich da mal durchgetestet. Sobald ich bei einem der beiden Aliassse einen Scope einbaue, kommt dieses Phänomen. Da ist es dann auch egal welcher Alias den Scope bekommt. Immer wird der Alias mit den aktuellen Positionen korrekt angezeigt, der mit den Infopositionen falsch.

Jan

[UliTs]

Eine Fortsetzung des Problems mit dem Scope...

Ich habe die dbf mit den Positionen, die abgearbeitet werden sollen. In einem Browse sollen alle die Positionen angezeigt werden, die der angemeldete Mitarbeiter erledigen soll. Zur Info, damit der weiß was da noch alles zu gehört (um z. B. einen Karton in passender Größe für alle Artikel dieses Auftrages zu wählen), sollen in einem zweiten Browse alle anderen Artikel dieses Auftrages angezeigt werden. Das regel ich durch einen Filter, der auf die gescopten Positionen gelegt wird.

Es ist überhaupt kein Problem, die dbf 2x zu öffnen, und bei zweiten einen anderen Alias zu vergeben. Es ist überhaupt kein Problem, diese beiden unterschiedlichen dbf den beiden Browses zuzuordnen. Alle Artikel, die der Mitarbeiter abarbeiten soll, werden auch ganz korrekt angezeigt. Aber in dem anderen Browse werden nicht z. B. 10 weitere Positionen angezeigt, sondern in einer der Anzahl Positionen im ersten Browses entsprechenden Anzahl Zeilen mit immer die gleiche Position. Die zwar in diesen Browse gehört, aber nicht z. B. 3x, nur weil im anderen Browse ganz korrekt 3 abzuarbeitende Positionen angezeigt werden. Und natürlich auch nicht 3x die gleiche Position.

Jan

Ich muß gestehen, den hervorgehobenen Teil habe ich nicht verstanden. Vielleicht muß ein Refresh über die Tabelle und den Browser gemacht werden? Testweise könntest Du die Tabelle des zweiten Browsers schließen und wieder öffnen.
Könntest Du ein einfaches Bildschirm-Beispiel konstruieren und zeigen, wie es derzeit falsch ist bzw. wie es richtig sein soll?

[AUGE_OHR]

Ich habe mich da mal durchgetestet. Sobald ich bei einem der beiden Aliassse einen Scope einbaue, kommt dieses Phänomen. Da ist es dann auch egal welcher Alias den Scope bekommt. Immer wird der Alias mit den aktuellen Positionen korrekt angezeigt, der mit den Infopositionen falsch.

das die beiden DBF verschiedene ALIAS() haben ist klar aber du scheinst ja auch eine INDEX zu haben (sonst könntest du kein SCOPE setzten)

wenn du nun im 1st Browse eine Aktion machst welcher den INDEX ändert und dieser auch im 2nd Browse aktive ist ...

[UliTs]

Jimmy, das darf keine Rolle spielen, sonst liegt ein Bug vor!
Mal sehen, ob sich Jan noch einmal meldet...

Uli

[Jan]

Das WLan hier auf den Xbase-Tracks ist - nahezu nicht existent. Sorry, ich kann daher nicht viel Online sein.

Ich hab gestern mit Andreas über das Problem gesprochen. Der Code scheint soweit OK zu sein. Ich werde ihm eine kleine Musteranwendung fertig amchen, die er sich nächste Woche im Büro dann ansehen wird.

Jan

[UliTs]

Danke für die Info, Jan.

[Jan]

So, das Problem ist gelöst. Wir haben heute mit der XUG mit vier Personen knapp 1 Stunde davor gesessen, dann war die Lösung da.

Der Punkt war, das die Bewegungen in den Navigations-Codeblöcke der beiden Browses jeweils den Alias davorgesetzt bekommen müssen. Es reicht nicht, das der Browse über die :datalink den richtigen Alias haben. DbSkipper etc. müssen den ebenfalls bekommen.

Noch einmal vielen Dank für Eure ganzen Tipps und Hinweise.

Jan

[Martin Altmann]

Stichwort: ungenügende Kapselung.

[AUGE_OHR]

Jimmy, das darf keine Rolle spielen, sonst liegt ein Bug vor!

nun hat sich Jan gemeldet

Der Punkt war, das die Bewegungen in den Navigations-Codeblöcke der beiden Browses jeweils den Alias davorgesetzt bekommen müssen. Es reicht nicht, das der Browse über die :datalink den richtigen Alias haben. DbSkipper etc. müssen den ebenfalls bekommen.

und das ist genau das was ich mit dem Record Pointer meine was mit dem "DbSkipper" dann passiert.
Deshalb habe ich ja auch 2 "getrennte" Browse (Class), vorzugsweise im Thread, vorgeschlagen die natürlich ihren "eigenen DbSkipper" dann hätten.

ob es mit den beiden ALIAS nun wirklich stabil ( im Netzwerk ?) läuft wird man, speziell bei Power Usern, schnell merken

[Tom]

Ich hatte das schon ganz am Anfang im Originalthread geschrieben: ... oder eben die Navi-Codeblöcke nicht stimmen

Tatsächlich kann man mit allgemeinen Navi-Codeblöcken für mehrere Workareas arbeiten, muss dann aber dafür sorgen, dass im Navi-Fall immer auch die richtige Workarea selektiert ist. Wenn das nicht der Fall ist, navigiert das Browse in der falschen, zeigt aber (weil die Datalinks richtig sind) die Daten aus der korrekten an.

[Martin Altmann]

Und genau das war hier das Problem. Fiel Andreas dann als erstem auf.

Viele Grüße,
Martin

[UliTs]

...Der Punkt war, das die Bewegungen in den Navigations-Codeblöcke der beiden Browses jeweils den Alias davorgesetzt bekommen müssen. Es reicht nicht, das der Browse über die :datalink den richtigen Alias haben. DbSkipper etc. müssen den ebenfalls bekommen.
---

Hallo Jan, kannst Du bitte den Codeblock für die :datalink zeigen?
Uli

[AUGE_OHR]

kannst Du bitte den Codeblock für die :datalink zeigen?

warum willst du den "falschen" o:Datalink sehen wenn das Problem in den Navigations-Codeblöcke lag ?!

wenn du die Navitations Codeblöcke erstellst

Code: Alles auswählen

oBrowse:skipBlock     := {|n| DbSkipper(n) }

wird die FUNCTION DbSkipper()***, die nicht "gekapselt" ist, aufgerufen und keine Methode von XbpBrowse()
*** in c:\ALASKA\XPPW32\Source\SYS\BrowUtil.prg

IMHO sollte man nicht mehr FUNCTION in den Navitations Codeblöcke verwenden sondern eine Class mit Methoden.

Code: Alles auswählen

INLINE METHOD GuiBrowseDB( oParent, aPos, aSize ) 
...
      // Navigationscodeblöcke für den Browser    
      self:oBrowse:skipBlock     := {|n| self:DbSkipper(n) } 
      self:oBrowse:goTopBlock    := {| | self:DbGoTop()    } 
      self:oBrowse:goBottomBlock := {| | self:DbGoBottom() } 
      self:oBrowse:phyPosBlock   := {| | self:Recno()      } 

      // Navigationscodeblöcke für den vertikalen Scrollbar 
      self:oBrowse:posBlock      := {| | self:DbPosition()    } 
      self:oBrowse:goPosBlock    := {|n| self:DbGoPosition(n) } 
      self:oBrowse:lastPosBlock  := {| | 100             } 
      self:oBrowse:firstPosBlock := {| | 0               } 

INLINE METHOD DbSkipper(n)
INLINE METHOD DbGoTop()
INLINE METHOD DbGoBottom()
INLINE METHOD Recno() 
INLINE METHOD DbPosition() 
INLINE METHOD DbGoPosition(n)

ob DBF oder SQL wäre dem Browse egal ...

[Tom]

Eine abgeleitete Browse-Klasse kann auch einfach über eine neue iVar verfügen, die die Datenquelle referenziert (Alias der DB oder Name des Arrays), und diese könnte dann in allen allgemeinen Navi-Codeblöcken verwendet werden (und z.B. auf das aktuelle Alias defaulten). So mache ich das, einfach gesagt. Oder man stellt eben sicher, dass vor der Navigation immer und in jeder Situation auch die richtige Workarea selektiert wird. Was bei zwei parallelen Browses ein wenig kompliziert werden kann.

[UliTs]

Du hast Recht, Jimmy. Ich habe da ein Problem gesehen, was es gar nicht gibt, wenn man sauber programmiert .
Tom, ich mache es genauso wie Du.

Uli