XbpBrowse() Satzmarkierung [Erledigt]

[Jan]

Moin,

ich steht da gerade ein wenig auf dem Schlauch. Ich mache ein XbpBrowse auf ein Array. Dabei arbeite ich das Array Satz für Satz ab, und lösche gegebenfalls Sätze im Array. Das klappt auch alles soweit einwandfrei.

Bis auf einen Punkt: Die Satzmarkierung steht immer auf dem obersten Satz. Auch wenn der aktuell abgearbeitete Satz weiter unten steht. Ich habe das im Debugger getestet: Es wird tatsächlich der korrekte Satz im Array abgearbeitet, der Browse steht da tatsächlich drauf. Nur die Markierung steht auf einem falschen Satz. Der Fehler liegt also in der Optik, nicht in der Logik.

Dummerweise finde ich nirgends etwas, mit dem ich die Satzmarkierung korrekt setzen kann.

Wo liegt da mein Denkfehler?

Jan

[Wolfgang Ciriack]

Ich denke, du must beim abarbeiten immer ein oBrowse:Down() und Refresh machen.

[Jan]

Moin Wolfgang,

ja, so klappt das. Danke für den Tipp. Da war ich vollkommen auf der falschen Spur gewesen, ich willte die Markierung manuell auf den richtigen Satz legen.

Aber warum macht der das nicht von alleine? Sollte der Browse nicht eigenständig die Anzeige mit der Datenbasis synchronisieren?

Jan

[azzo]

Hallo Jan,
KI Antwort - doch ich glaube trotzdem interessant.
LG
Otto

Hintergrund zum Problem
In Xbase++ (Alaska) werden `XbpBrowse`-Objekte üblicherweise für den „optischen“ Teil einer Datentabelle verwendet, während die eigentliche Datennavigation (also der sogenannte „Record Pointer“) bei DBF-Tabellen in der Workarea liegt – oder bei Arrays in einem Array-Adapter oder einer selbst programmierten Logik. Das bedeutet, dass das `XbpBrowse` in vielen Fällen nur dann automatisch die Markierung (den visuellen Selektionsbalken) verschiebt, wenn

entweder die Workarea (DBF) durch einen dbSkip(), dbGoto(), etc. den Datensatzzeiger verändert,
oder man ein passendes „Datenobjekt“ / „Daten-Adapter“ (z.B. ein DataSource-Objekt) verwendet, das die Navigation übernimmt,
oder bei reinen Arrays den entsprechenden Pointer in der Browse-Logik explizit aktualisiert und den Browse neu zeichnet.
Warum „hakt“ die optische Markierung?
Wenn man in einer Schleife das Array durchgeht und ggf. Datensätze löscht oder verändert, arbeitet man zwar logisch korrekt (der richtige Satz wird verarbeitet), aber das `XbpBrowse`-Objekt wird ggf. nicht „automatisch“ darüber informiert, dass jetzt eine andere Zeile im Array als gerade aktiver Satz gelten soll.

Sprich: Dein Code „weiß“ zwar, dass jetzt z.B. Element [15] im Array zu bearbeiten ist, aber das `XbpBrowse` selbst steht vielleicht immer noch auf dem ersten Eintrag, weil es keinen expliziten Befehl bekommt, sich dort hinzubewegen.

Typische Lösungswege
1. oBrowse:SetPos() bzw. oBrowse:Skip() nutzen
Einer der bekanntesten Ansätze in Xbase++ ist es, die Browse-Position (Zeilennummer) direkt zu setzen. Hierfür gibt es u.a. die Methode SetPos(), mit der Du das `XbpBrowse` auf eine bestimmte Zeilennummer bewegen kannst. Zum Beispiel:

xbase
Code kopieren
oBrowse:SetPos( nIndex, XBPBRW_REL_TOP )
oBrowse:DrawSelectBar() // neu zeichnen, damit man es sieht
nIndex ist hierbei die (1-basierte) Zeilennummer im aktuellen Ausschnitt des Browses.
Alternativ kann man mit SetPos( nZeilenOffset, XBPBRW_RELATIVE ) relativ zum aktuellen Satz die Browse-Position verschieben.
Gerade wenn Du in einer Schleife dein Array-Elemt `i` abarbeitest (z.B. FOR i := 1 TO Len(aMyArray)), kannst Du nach jeder Änderung oder jedem Löschen explizit das `XbpBrowse` „bitten“, sich neu auszurichten.

2. oBrowse:RowPos := <nZeile> (bei Array-Daten)
Wenn Du ein reines Array-Browse nutzt – also oBrowse:createFromArray(aMyArray, ...) oder eine ähnliche Technik – gibt es die Member-Variable RowPos, welche in vielen Fällen direkt die aktuelle Zeilennummer widerspiegelt. Wenn Du also in deiner Schleife weißt „ich will jetzt im Browse auf Zeile 15 springen“, kannst Du einfach schreiben:

xbase
Code kopieren
oBrowse:RowPos := 15
oBrowse:RefreshCurrent() // oder :RefreshAll(), je nachdem
Danach steht die optische Markierung auf Zeile 15.

Achtung: RowPos erwartet meistens eine 1-basierte Zeilennummer – also die Position im Array, nicht den Arrayindex 0-basiert.

3. Datenquelle über ein „DataObject“ (z.B. XbpArrayDataSource) verwalten
Eine elegantere, aber etwas aufwendigere Lösung ist, dem `XbpBrowse` ein richtiges „Datenquellen“-Objekt zu übergeben, das mit dem Array arbeitet und selbst für die Navigation zuständig ist. Beispielsweise kann man ein XbpArrayDataSource()-Objekt erstellen, das man dann dem `XbpBrowse` via BrowseSetDataSource() zuweist.

Sofern das DataSource-Objekt richtig konfiguriert ist, kann man auch darüber die Navigation (z.B. Skip(), GoTop(), GoBottom(), GoTo()) veranlassen, und das `XbpBrowse` bleibt automatisch synchron.

4. Vergiss nicht, das Browse neu zu zeichnen (Refresh)
Oft muss man nach einer Veränderung (z.B. Löschen eines Eintrags im Array) einen :RefreshAll() oder :RefreshCurrent() ausführen, damit das `XbpBrowse`-Objekt sich optisch neu aufbaut. Manchmal reicht auch ein :DrawSelectBar() oder :ForceStable() (je nach Kontext).

Gerade beim Löschen von Elementen aus dem Array kann es passieren, dass das `XbpBrowse` noch denkt, es gäbe mehr Einträge als nach dem Löschen tatsächlich vorhanden sind. Daher:

Neues Array übergeben (oder aDel() anwenden, je nachdem).
oBrowse:RefreshAll() aufrufen.
Zusammenfassung / „Denkfehler“
Der „Denkfehler“ liegt häufig darin, zu glauben, dass das `XbpBrowse` automatisch weiß, auf welchem Datensatz wir programmatisch (z.B. in einer Schleife) stehen. Anders gesagt: Der „Browse-Zeiger“ (optische Markierung) ist nicht automatisch der gleiche wie dein Array-Lesezeiger.

Wichtig ist also, dem `XbpBrowse` aktiv mitzuteilen, dass (und wo) es sich optisch hinbewegen soll, wenn Du den „aktuellen“ Satz im Array änderst. Dies kann man – je nach Datenmodus (DBF, Array, DataObject) – unterschiedlich lösen:

Array-Modus: `oBrowse:RowPos := nRow` + `oBrowse:Refresh...`
DBF-Modus: durch dbGoto(), dbSkip(), etc. (sofern oBrowse:lAutoAppend := .F. und Co. richtig stehen).
DataSource-Objekt: über DataSource:GoTo(), DataSource:Skip(), etc.
Sobald Du das machst, „rutscht“ die Markierung im Browse auch auf die richtige Zeile und passt sich dem an, was Du im Code (Schleife, Datensatzbearbeitung) tust.

Fazit:

Du musst nach jeder Änderung des Arrays bzw. nach jeder Navigation auch das `XbpBrowse` „anfassen“, damit es die gleiche Satzposition anzeigt.
Das geht z.B. mit `oBrowse:RowPos := <nZeile>` oder `oBrowse:SetPos(<nZeile>)` und anschließendem `oBrowse:RefreshAll()`.
Damit stellst Du sicher, dass der Browse-Balken wirklich auf dem Satz steht, der auch gerade im Code verarbeitet wird.

[RolandG]

Aber warum macht der das nicht von alleine? Sollte der Browse nicht eigenständig die Anzeige mit der Datenbasis synchronisieren?

Kann man schon so hinbiegen dass der Browse das "vermeintlich" selbst macht indem man z.B. den notwendigen Refresh-Block in jede Row/Col mit einbaut (verdeckt). Das wertet man dann bei jedem Vorgang aus.
Also ähnliche/gleiche Vorgehensweise wie Zeilen/Felder im Browse gezielt farbig markieren.

P.S.: SCHÖNE WEIHNACHTEN!

[Jan]

Otto,

wie so oft liegst Du vollkommen daneben. Das, was Deine ultrakluge KI ausgespuckt hat klappt nämlich nicht, da die Methoden in Xbase++ teilweise nicht existieren. Oder nicht das machen worum es hier eigentlich geht.

Wenn Du keine Ahnung hast von Xbase++ lass es doch einfach mal sein, und konzentriere Dich auf das wovon Du Ahnung hast.

Jan

[azzo]

Hallo Jan,

>Aber warum macht der das nicht von alleine? Sollte der Browser nicht eigenständig die Anzeige mit der Datenbasis synchronisieren?

Die Antwort auf deine Frage findest du oben. Ich finde, dass es gut erklärt ist.

Für mich sind die Themen hier interessant. Im Prinzip ist es dasselbe. Bei Harbour/FW ist der Browser aber komplett im Sourcecode verfügbar, und wir können uns die internen Abläufe anschauen. Dadurch ist der Browser und die interne Funktionsweise transparenter.

Was ich nicht verstehe, ist, dass, wenn es zu einem Thema eine Diskussion gibt, du dann entscheidest, dass es nun erschöpfend behandelt wurde.
Bist du nicht auch nur ein einfaches Vereinsmitglied hier, oder habe ich hier etwas übersehen?

LG
Otto

[Jan]

Otto,

Du mißinterpretierst hier so manches.

Ich bin in der Tat ein einfaches Vereins- und Foren-Mitglied. Ohne jede Sonderrechte. Wobei sich mir die Frage stellt warum das für Dich von Bedeutung sein könnte. Oder irgend etwas ändern sollte. Ich darf doch auch als einfaches Mitglied eigenständige Gedanken und Meinungen haben, oder?

Und ich habe nicht die Diskussion um die Ursache für meine Frage abgebrochen. Sondern Deine Antwort abgelehnt, die zwar sehr lang ist, aber in keinster Weise eine Lösung darstellt. Nicht mal eine Richtung vorgibt, in die man denken könnte. Da sie sehr viele Fehler enthält. Nicht Dein Problem, Du hast das ja nicht geschrieben. Und die KI scheint doch nicht sonderlich intellligent zu sein, wenn die nicht erkennt das die von ihr aufgeführten Methoden nicht auf die Datenbasis gehen sondern lediglich auf die GUI.

Und ich leugne auch nicht, das all die Themen, in denen Du hier umfassende Beiträge setzt, Dich interessieren. Nur passen diese oft abendfüllenden Beiträge nicht immer zu dem Thread, in dem Du die postest. Du nimmst regelmäßig Gedanken aus einem Thread auf, und denkst die in Deiner Richtung weiter. Was dann aber meist nur noch rudimentär mit dem auslösenden Thread selber zu tun hat. Besser wäre es wenn Du für solche Ausführungen einen neuen Thread öffnen würdest, um die eigentliche Diskussion nicht zu unterbrechen. Und in Deinem Thread können dann Deine Ideen zielführend weitergeführt werden, ohne das Antworten zum auslösenden Thread Deine Gedanken sinnlos unterbrechen.

Ich will auch nicht leugnen das so manches Deiner Themen auch für Andere von Interesse ist. Daher will ich auch gar nicht Deine Beiträge blocken. Aber eben halt nicht immer in den Threads zu anderen Themen. Das macht die produktiv Lesenden vollkommen irre.

Jan

[azzo]

Hallo Jan,

aber ist Punkt 2 nicht die Lösung für dich? Und in Punkt 3 (DataObject) wird erklärt, wie du es machen könntest, dass es automatisch funktioniert.

LG
Otto

[Jan]

Otto,

die Lösung hatte Wolfgang heute früh gepostet.

2) ginge vielleicht in anderen Situationen. In meiner wäre die erheblich zu kompliziert.

3) ist obsolet, weil ich in solchen Fällen grundsätzlich mit DataObjects arbeite. Sobald Sätze in einem Array mehr als drei oder vier Elemente haben wechsle ich fast grundsätzlich auf DO um, weil das erheblich übersichtlicher und einfacher zu handhaben ist. Und mir ist nicht klar was das in diesem Fall für einen Unterschied machen sollte.

Jan

[brandelh]

vor ewigen Zeiten hab ich mich da auch drüber geärgert, es könnte besser geregelt sein,
aber wie immer gibt es eben ein Problem mit beiden Ansätzen.

Ein RefresAll() zu oft und der Rechner flackert wie ein Weihnachtsbaum, das Refresh der Zeile ist weniger lästig, aber eben nicht perfekt.

[RolandG]

Hallo Jan
auch wenn schon als [Erledigt] markiert noch ein paar Zeilen von mir:
* über Jahre habe ich XbpBrowse soweit aufgebohrt (aufgebläht) ,
dass ich XbpBrowse für möglichst alle Tabellen-Anzeigen und Auswahl-Tabellen verwende (z.B. AChoice() ),
* für einfache, kurze Arrays genauso wie große Arrays,
* für DBF-Anzeigen,

Die Kommunikation mit XbpBrowse ist je nach Umfang der gewünschten Anzeige von einfach bis recht kompliziert (viel Schreibarbeit je Feld/Zeile/Spalte).

Wenn ich hier Quellcode reinstelle wird kaum jemand was damit anfangen können, bei Interesse kann ich das aber zeigen (Remote).

[Tom]

Der Quellcode von XbpBrowse ist übrigens auch in der ProfSub enthalten.

Otto, hast Du nix anderes zu tun als sämtliche Threads zu shreddern? Die meisten hier nutzen Xbase++ professionell, also als Werkzeug in ihrem beruflichen Alltag. Mit abseitigen Themen oder Ballaballa-Bullshit aus dem generative pretrained transformer verschwendest Du hier nur Zeit, und zwar unsere.

[Tom]

über Jahre habe ich XbpBrowse soweit aufgebohrt (aufgebläht), dass ich XbpBrowse für möglichst alle Tabellen-Anzeigen und Auswahl-Tabellen verwende (z.B. AChoice() ),

Ja. Von XbpBrowse() als Basisklasse lassen sich mit den jeweils passenden Sets an Navigations-Codeblöcken (!) sehr leicht generische Grids für alle denkbaren Datenquellen ableiten, von der Tabelle über das klassische Array bis hin zum Array aus Datenobjekten oder - wie bei uns in vielen Fällen - gemischten Datenquellen (z.B. Arrays aus Codeblöcken, die auf unterschiedliche Tabellen verweisen - oder auf komplexe Ergebnisse von Auswertungen). Ergänzt man um Ownerdrawing, kann man sogar halbwegs ausgleichen, dass die starre Systematik von XbpBrowse (einheitliche Zeilenhöhen je Segment Heading/DataArea/Footing einer Column) Dinge nicht zulässt, die man heutzutage von einem Grid erwarten würde. Wir haben via Ownerdrawning XbpBrowse-Klassen gebaut, die auch in der Darstellung alles mögliche innerhalb einer Zelle mischen können - Icons, wechselnde Schriftarten, andere grafische Elemente. Theoretisch lässt sich das auch mit HTML oder anderen Markup-Beschreibungssprachen realisieren. Man muss nur darauf achten, dass man sich beim Zeichnen im UI-Thread befindet, also anderswo als die Datenquelle selbst.