DBGrid und Touchscreen

[Sir Rufo]

Hmmm, bevor ich da sonn Aufstand um das Zählen und Positionsbestimmen machen würde, packe ich den ganzen Kram in eine Klasse TBon mit einer TBonPosList

Die Klasse macht dann den ganzen Kladeradatsch (völlig ohne DB-Zugriffe - ja bis auf die Abfrage der Stammdaten) und zeichne das in ein ListView rein (oder wo auch immer)

[noisy_master]

Zitat von GHorn:

Performanz hängt von mehr als nur dem Scrollen ansich ab.
Da spielt die verbaute Hardware auch eine Rolle. Außerdem
scrollst du ja nicht durch 100e DS. Immer nur einen Schritt
vor und einen zurück und umgekehrt.
Aber das musst du selber testen.

Alles soweit gut, eingebaut, getestet und macht (fast) alles was ich will.

Dein Code muss noch ein wenig modifiziert werden, damit es auch vollständig funktioniert:
DBGrid.DataSource.DataSet.DisableControls;
// BOF:
DBGrid.DataSource.DataSet.Prior;
Btn_UP.Enabled := (NOT DBGrid.DataSource.DataSet.BOF);
>> if Btn_UP.Enabled then
DBGrid.DataSource.DataSet.Next;
// EOF:
DBGrid.DataSource.DataSet.Next;
Btn_Down.Enabled := (NOT DBGrid.DataSource.DataSet.EOF);
>> if Btn_Down.Enabled then
DBGrid.DataSource.DataSet.Prior;
DBGrid.DataSource.DataSet.EnableControls;


Tja, bleibt immer noch das Ding mit der RecordNo...

[Bummi]

geht jetzt OT aber vielleicht solltest Du die BDE doch mal kicken und das ganz aus MS-SQLServer, Access o.ä. umstellen und per ADO weitermachen.

[noisy_master]

Zitat von Sir Rufo:

Hmmm, bevor ich da sonn Aufstand um das Zählen und Positionsbestimmen machen würde, packe ich den ganzen Kram in eine Klasse TBon mit einer TBonPosList

Die Klasse macht dann den ganzen Kladeradatsch (völlig ohne DB-Zugriffe - ja bis auf die Abfrage der Stammdaten) und zeichne das in ein ListView rein (oder wo auch immer)

Auch das klingt sehr gut! Aber leider ist auch dort ein relativ großes Re-Design nötig...Aber Gut!!!Echt!!!

[noisy_master]

Zitat von Bummi:

geht jetzt OT aber vielleicht solltest Du die BDE doch mal kicken und das ganz aus MS-SQLServer, Access o.ä. umstellen und per ADO weitermachen.

Jaaaaaaa doch, aber nicht jetzt!!!!

Kommt Zeit, kommt Rat, kommt andere Datenbank...

[stahli]

Ich will mal die Fragezeichen noch aufklären

Du hast nicht erklärt,
- um wie viele Datensätze es sich handelt
- wie oft die Query aktualisiert wird
- wie komplex die Joins sind
- wieviel Daten geändert werden können
- was Du als zeitkritisch beim Scrollen betrachtest
- ob es pro Datensatz eine eindeutige und aufsteigende ID gibt
- (ob es Alternativen zur BDE gibt)

Daher muss ich bzw. müssen wir etwas orakaln...
Als Ansätze würde ich grundsätzlich folgendes sehen:

1) Daten in Objekten verwalten und zurückschreiben (wie der Sir meinte)

2) temporäre Tabelle erstellen (und TTable benutzen) und nach den Änderungen wieder in die originalen Tabellen zurüchschreiben

3) DBGrid.DrawDataCell
Sofern Du ein eindeutiges Indexfeld in der Ergebnismenge hast, kannst Du diesen Wert wärend des Zeichnens der Zellen ermittel. Das wird z.B. genutzt, um DBGrid-Zeilen, bei Negativwerten rot zu färben.
Du könntest das verwenden, um die Button zu (de-)aktivieren. Dazu müsstest Du den niedrigsten und höchsten Wert kennen und darauf abgleichen. Das ist nicht simpel, aber durchaus möglich.
Es wäre auch möglich, nach dem Abrufen einer Query alle "Indizes" in eine Stringlist zu kopieren und beim scrollen die Postion aus der Stringlist zu ermitteln.
MyCursor := StringList.IndexOf(MyField.AsString) + 1; Das ist alles nicht optimal, aber was für Dich das sinnvollste ist, musst Du letztlich selbst entscheiden (je nachdem was genau für Daten vorliegen und was Du mirt dem Projekt weiter vor hast).

[noisy_master]

Zitat von stahli:

Ich will mal die Fragezeichen noch aufklären

Du hast nicht erklärt,
- um wie viele Datensätze es sich handelt
- wie oft die Query aktualisiert wird
- wie komplex die Joins sind
- wieviel Daten geändert werden können
- was Du als zeitkritisch beim Scrollen betrachtest
- ob es pro Datensatz eine eindeutige und aufsteigende ID gibt
- (ob es Alternativen zur BDE gibt)

Daher muss ich bzw. müssen wir etwas orakaln...
Als Ansätze würde ich grundsätzlich folgendes sehen:

1) Daten in Objekten verwalten und zurückschreiben (wie der Sir meinte)

2) temporäre Tabelle erstellen (und TTable benutzen) und nach den Änderungen wieder in die originalen Tabellen zurüchschreiben

3) DBGrid.DrawDataCell
Sofern Du ein eindeutiges Indexfeld in der Ergebnismenge hast, kannst Du diesen Wert wärend des Zeichnens der Zellen ermittel. Das wird z.B. genutzt, um DBGrid-Zeilen, bei Negativwerten rot zu färben.
Du könntest das verwenden, um die Button zu (de-)aktivieren. Dazu müsstest Du den niedrigsten und höchsten Wert kennen und darauf abgleichen. Das ist nicht simpel, aber durchaus möglich.
Es wäre auch möglich, nach dem Abrufen einer Query alle "Indizes" in eine Stringlist zu kopieren und beim scrollen die Postion aus der Stringlist zu ermitteln.
MyCursor := StringList.IndexOf(MyField.AsString) + 1; Das ist alles nicht optimal, aber was für Dich das sinnvollste ist, musst Du letztlich selbst entscheiden (je nachdem was genau für Daten vorliegen und was Du mirt dem Projekt weiter vor hast).

Nachdem du denn nun schon soviel geschriebe hast will ich deine Fragen mal nicht unbeantwortet lassen:

Alternative zur BDE: im Moment nicht!
Aufsteigende eindeutige ID: ja gibt es, aber leider keine kontinuierliche
Was ich als Zeitkritisch betrachte: Wenn ich mi anschaue, in welcher Geschwindigkeit die Jungs im
Restaurant auf den Screen einhämmern möchte ich jede (unnötige/umgehbare) Geschwindigkeitseinbuße vermeiden.
Wieviele Daten können geändert werden: nicht allzuviele( Bestellung kommt hinzu, Artikel kommen hinzu, es wird gedruckt... also immer nur einzelne Felder/einzelne Datensätze)
Wie komplex sind die Joins: nicht allzusehr, jeweils einzelne Verweise auf Kellnernummern bzw Artikelnummern oder Rechnungsnummern
Wann wird das Query aktualisiert: immer dann, wenn sich an den Datensätzen was ändert.
Wieviele Datensätze: Ein klares kommt drauf an : Wenn viel los ist sind es mehr... Nun nochmal ohne Scherz: Nimm die eine durchschnittliche Pizzeria mit meinetwegen 30 Tischen und 2 Bedienungen-> Anzahl offenen Bons ~max 15 und Artikel/Bestellung je nach Hunger der Kunden also ~20 Artikel pro Bestellung

Hält sich in Summe in Grenzen, aber wenn sich an irgendwelchen Stellen durch geschicktes programmieren Performance gewinnen lässt ist das immer gut.

Deinen Aussagen zu den bisherigen Vorschlägen stimme ich zu.

[GHorn]

Solch eine erläuternde Ausführung hilft allen, die helfen wollen
und macht sich auch immer gut am Threadanfang

[Neumann]

Hallo,

möchte dem Entwickler ja nicht unbedingt mutlos machen, aber so wie ich es lese ist sein Kassenprogramm noch im Anfangsstadium. Es gibt sehr viele solche Kassenprogramme am Markt; z.T. zu Preisen unter 100 €. Viel davon sind allerdings auch grottenschlecht und oft mit Visual Basic zusammengekloppt.

Um ein halbwegs brauchbares Produkt zu entwickeln, braucht man nach meiner Erfahrung mindestens 3 Jahre. Am Anfang habe ich das auch nicht geglaubt. Ob sich das dann vermarkten lässt ist eine zweite Frage. Bitte dies nicht falsch verstehen; sicher wir verkaufen Kassenprogramme, es geht mir mit meinem Posting nicht darum, mögliche Mitbewerber zu verhindern. Es spielt eigentlich keine Rolle ob es 100 oder 101 oder 110 Mitbewerber gibt, und ich sehe Mitbewerber primär als Kollegen und habe auch Kontakt zu einigen.

Zur Technik
Man sollte die BDE sofort über Bord werfen und eine zeitgemäße Datenbank verwenden wie Firebird, Postgresql oder MSSQL; sonst handelt man sich unnötige Probleme beim Betreiben der Kassen im Netzwerk ein, weiter gibt es auch Probleme mit Windows 7 wegen des nicht mehr vorhandenen 16 Bit Subsystems.

Das Scrollen in der Ansicht (dbgrid) ist eigentlich nur ein Randproblem. Wie glaube ich schon gesagt mit zwei Buttons für dataset.prior und dataset.next einfach zu lösen.

Gruß

Ralf

[noisy_master]

Zitat von GHorn:

Solch eine erläuternde Ausführung hilft allen, die helfen wollen
und macht sich auch immer gut am Threadanfang

Hast ja in Summe Recht, aber diese Informationen helfen nicht wirklich bei dem eigentlichen Problem, das ich eigentlich IMHO recht gut erklärt hatte