DBGrid und Touchscreen

[noisy_master]

Hallo Gemeinde,

mein Problem ist eigentlich ganz einfach: Ich entwickele ein Kassensystem mit Touchscreen. Die DBGrids(verschiedenste JVDBGrid, cyAdvDBGrid und noch einige mehr, die ich ausprobiert habe) funktionieren mit den dazu passenden Querys...alles gut soweit. Jetzt kommt es:

Die Scrollbars, die standartmässig am DBGrid hängen lassen sich per Touch eigentlich nicht bedienen, da sie viel zu klein sind. Nun zu meiner Frage hat irgendwer eine Idee, wie ich meine Scrollbars so groß bekomme, dass ich diese vernünftig bedienen kann? Es müssen auch nicht unbedingt Scrollbars sein(die könnte man ja ausblenden(über ein Hacked DBGrid, bzw einige DBGrid-Abkömmlinge unterstützen das ja von Haus aus))
Die Variante die Scrollbars Systemweit mit SystemParametersInfo(SPI_SETNONCLIENTMETRICS, sizeOf(currentMetrics), @currentMetrics, SPIF_SENDCHANGE); breiter zu machen halte ich auch für nicht die Beste Lösung(ausserdem funktioniert das bei DBGrids nicht(warum?)). Man könnte auch einfach Buttons nehmen und über diese ein Next und ein Prior auf den Query absetzen, aber die Button sollten dann auch am Anfang bzw. am Ende des Querys jeweils deaktiviert werden, damit der User weiss, dass es hier nicht mehr weitergeht. Hier kommt aber wieder das nächste Problem: Die RecNo entspricht ja leider der Nummer in der gesamten Tabelle, und damit weiss man leider nicht genau wo man gerade ist. Eof/Bof funktioniert auch nicht so gut, da Eof/Bof ja hinter bzw vor dem letzten/ersten Record liegt. Die Varianten mit den abgeleteten DBGrids, die Row und RowCount liefern taugen auch alle nicht, da Row leider immer nur den sichtbaren Zeilen entspricht, TopRow immer = 1 ist(auch hier wieder die Frage warum eigentlich?)...

Wie man sieht ich habe schon etliches ausprobiert, aber immer noch keine Lösung gefunden, die mich zufriedenstellt. Hat hier irgendwer noch noch eine gute Idee? Ich bin für jede dankbar.

Am liebsten wäre es mir wenn man die originalen Scrollbars "ersetzen" könnte

Freue mich auf viele hilfreiche Antworten

[Sir Rufo]

Das mit einem DBGrid ist totaler Murks (bei Touch)

Ich würde einen statischen Anzeigebereich nehmen und dort n Zeilen anzeigen lassen

Daneben Buttons mit denen man navigieren kann.

Sehr schön ist natürlich eine Komponente die man iPhone-like scrollen könnte, aber der gemeine Kassierer hat eigentlich lieber was festes unter den Händen

[noisy_master]

o.k. Das mit dem festen Anzeigebereich ist eine recht gute Idee, bedarf aber dann eines größeren Re-Designs. Damit ist diese Option(zumindest im Moment) für mich vom Tisch.

Gibt es noch Ideen zu meiner Fragestellung?

[divBy0]

Stimmt, das mit dem Grid ist Mist bei Touch.

Wenn es trotzdem ein DBGrid sein soll, könntest du, wenn du D2010 hast, mit Gesten arbeiten und so das DBGrid scrollen.

Andernfalls könntest du z.B. 5 Datensätze übersichtlich in TEdits oder TLabels darstellen und die nächsten 5 Datensätze per Button oder auch per Geste laden und somit scrollen.

[noisy_master]

Zitat:

Zitat von divBy0 (Beitrag 1055476)

Stimmt, das mit dem Grid ist Mist bei Touch.

Wenn es trotzdem ein DBGrid sein soll, könntest du, wenn du D2010 hast, mit Gesten arbeiten und so das DBGrid scrollen.

Andernfalls könntest du z.B. 5 Datensätze übersichtlich in TEdits oder TLabels darstellen und die nächsten 5 Datensätze per Button oder auch per Geste laden und somit scrollen.

o.k. auch eine Gute Idee, geht aber auch auf die Idee mit dem festen Anzeigebereich zurück.
Beantwortet aber leider auch nicht die Fragen aus dem 1. Post.
BTW: Wie willst du eigentlich verschieden Datensätze in TLabels/TEdits darstellen? Die beziehen sich doch meines erachtens immer nur auf den aktuellen Datensatz, oder?

Sorry, hast natürlich recht, hatte TDBEdit/TDBLabel gelesen....Mea Culpa!

[divBy0]

Das geht nicht auf den festen Anzeigebereich zurück. Ein DBGrid hat die Methode ScrollBy(X, Y). Damit kannst du sogar über einfache Button hoch-/runterscrollen.

[noisy_master]

Zitat:

Zitat von divBy0 (Beitrag 1055488)

Das geht nicht auf den festen Anzeigebereich zurück. Ein DBGrid hat die Methode ScrollBy(X, Y). Damit kannst du sogar über einfache Button hoch-/runterscrollen.

o.k. Das hört sich schon viel besser an! Jetzt bleibt aber noch die Frage nach dem Deaktivieren der Hoch/Runter Buttons am Ende bzw Anfang des Querys

[Sir Rufo]

Das DataSet hat alle Informationen gespeichert
Position im DataSet, Anzahl der Records, etc.

[noisy_master]

Zitat:

Zitat von Sir Rufo (Beitrag 1055496)

Das DataSet hat alle Informationen gespeichert
Position im DataSet, Anzahl der Records, etc.

Wie komme ich denn an die Position? Anzahl der Records ist in RecordCount drin, das ist richtig, aber die RecNo kann man nicht gebrauchen(gibt afaik die Rosition in der gesamten Tabelle an)

[Sir Rufo]

RecNo bezieht sich auf das DataSet und gibt die Position innerhalb dessen an

[noisy_master]

Zitat:

Zitat von Sir Rufo (Beitrag 1055500)

RecNo bezieht sich auf das DataSet und gibt die Position innerhalb dessen an

Leider nicht, sonst hätte ich es benutzt. Evtl liegt das daran, dass der Query ein LiveRequest ist!?!

[Bummi]

Tja die leidige BDE, per Ado kannst/Willst Du nicht zugreifen?

[noisy_master]

Zitat:

Zitat von Bummi (Beitrag 1055536)

Tja die leidige BDE, per Ado kannst/Willst Du nicht zugreifen?

Im Moment wird es leider bei der BDE bleiben(Irgendwann wird auf Firebird, FlashFiler, AbsoluteDB oder was auch immer umgestellt). Gibt es nun eine sinnvolle Lösung für die BDE?

[Bummi]

Hmmm, bleibt noch BOF und EOF zum schalten der Buttons.

[noisy_master]

Zitat:

Zitat von Bummi (Beitrag 1055576)

Hmmm, bleibt noch BOF und EOF zum schalten der Buttons.

Leider gibt es auch da ein Problem: Wenn du mit query.next zum letzten Datensatz kommst ist EOF immer noch false, erst wenn du dann nochmal next sendest ist EOF True(ähnliches gilt für BOF), Damit werden die Buttons jeweils 1 Record zu spät deaktiviert(schön wäre eine Abfrage auf isLast oder isFirst)

[GHorn]

Z.B. EOF feststellen. Das BOF ist entsprechend umzubauen.

Button "Runter":

Delphi-Quellcode:

   ....
   DBGrid.DataSource.DataSet.Next;
   // Nachsehen, ob's der letzte DS ist:
   DBGrid.DataSource.DataSet.DisableControls;
   DBGrid.DataSource.DataSet.Next; 
   Btn_Down.Enabled := (NOT DBGrid.DataSource.DataSet.EOF);
   DBGrid.DataSource.DataSet.Prior;
   DBGrid.DataSource.DataSet.EnableControls;

[noisy_master]

Zitat:

Zitat von GHorn (Beitrag 1055587)

Z.B. EOF feststellen. Das BOF ist entsprechend umzubauen.

Button "Runter":

Delphi-Quellcode:

   ....
   DBGrid.DataSource.DataSet.Next;
   // Nachsehen, ob's der letzte DS ist:
   DBGrid.DataSource.DataSet.DisableControls;
   DBGrid.DataSource.DataSet.Next; 
   Btn_Down.Enabled := (NOT DBGrid.DataSource.DataSet.EOF);
   DBGrid.DataSource.DataSet.Prior;
   DBGrid.DataSource.DataSet.EnableControls;

Soweit, so gut. Ich hatte nur gehofft, dass das etwas einfacher ginge:?.
Jetzt noch der letzte Punkt: Wenn der User nun den letzten Datensatz auf dem Grid auswählt soll natürlich der "down" Button auch deaktiviert werden->wieder die Frage: wie bekomme ich mit, dass das der letzte Datensatz war?

[GHorn]

:gruebel: Hast du den Codeschnipsel schon mal ausprobiert?
Der soll doch genau das machen. Oder habe ich deine Frage
falsch verstanden?

[noisy_master]

Zitat:

Zitat von GHorn (Beitrag 1055592)

:gruebel: Hast du den Codeschnipsel schon mal ausprobiert?
Der soll doch genau das machen. Oder habe ich deine Frage
falsch verstanden?

DA hast du wohl leider die Frage falsch verstanden: Wenn der User nun sagen wir die letzten 5 Records im Grid sieht, und im Moment der 1. davon selektiert ist und der User nun den allerletzten auswählt(nicht per Down Button, sondern direkt im Grid) soll der Down Button auch deaktiviert werden.

[GHorn]

Das würde ich DBGrid.OnClick genauso verarbeiten.

[noisy_master]

Zitat:

Zitat von GHorn (Beitrag 1055595)

Das würde ich DBGrid.OnClick genauso verarbeiten.

Ist dann nur schwierg zu entscheiden ob ich für BOF oder EOF testen soll, oder sehe ich da was falsch?

[GHorn]

Einfach beide Richtungen abfragen:

Delphi-Quellcode:

   DBGrid.DataSource.DataSet.DisableControls;
   // BOF:
   DBGrid.DataSource.DataSet.Prior;
   Btn_UP.Enabled := (NOT DBGrid.DataSource.DataSet.BOF);
   DBGrid.DataSource.DataSet.Next; 
   // EOF:
   DBGrid.DataSource.DataSet.Next; 
   Btn_Down.Enabled := (NOT DBGrid.DataSource.DataSet.EOF);
   DBGrid.DataSource.DataSet.Prior;
   DBGrid.DataSource.DataSet.EnableControls;

[Bummi]

Runscrollen muß IMHO nicht sein.
Ist 10 jahre her daß ich mich mit der BDE rumschlagen mußte
aber gab es da nicht DbiGetNextRecord, DbiGetPriorRecord gegf. in der DBTables nachschlagen. und Googlen

[GHorn]

Ja schon, das gibt's auch. Wenn ich mich recht erinnere (ist
für mich auch schon etliche Monde her) wird dabei der nächste
Datensatz komplett eingelesen und der jeweilige DS ist aktiv.
Da passiert dann noch mehr als beim einfachen Skippen, oder?

[stahli]

Als Notlösung könnte man evtl. von Hand mitzählen.
Die RecordCounts sind ja bekannt und wenn das Scrollen NUR über Buttons geht, kann man die Position mitzählen...

Delphi-Quellcode:

Inc(Position, 3)

(RecNo unter den Umständen wird schwierig werden.)

[noisy_master]

Zitat:

Zitat von stahli (Beitrag 1055603)

Als Notlösung könnte man evtl. von Hand mitzählen.
Die RecordCounts sind ja bekannt und wenn das Scrollen NUR über Buttons geht, kann man die Position mitzählen...

Delphi-Quellcode:

Inc(Position, 3)

(RecNo unter den Umständen wird schwierig werden.)

Da Hast du recht kann man machen ist aber tatsächlich nur möglich wenn nur die Buttons benutzt werden. Da der User aber auch direkt auf dem Grid auswählen können soll wird das leider nichts!!!

[noisy_master]

Bisher echt schöne Antworten von GHorn:thumb:
Das einzige, was mich daran noch stört ist das "herumscrollen" Wenn das nur irgendwie schöner ginge...(ist ja wohl auch nicht ganz so performant)?!?

Jetzt noch die letzte Klinke :

Wenn ich nun noch gerne die anzeige Datensatz x /y haben möchte...? y ist klar : RecordCount, aber x? RecNo geht ja nun nicht(wie schon in den vorigen Posts angesprochen)

Gibt's da nicht auch was von Ratiopharm äähh BDE?

[stahli]

Ok, dann sind die Buttons vielleicht doch überflüssig!?

Vielleicht noch etwas dreckiger: :-D
Du könntest die Position beim Zeichnen der Zellen ermitteln. Entweder hast Du Direkt ein Feld mit einer "RecordNummer" oder Du prüfst (wenn Du einen eindeutigen Sortwert hast) mit einem SQL-Select, ob bei der letzten Grid-Darstellung der erste oder letzte Datensatz gezeichnet wird/wurde.

[noisy_master]

Zitat:

Zitat von stahli (Beitrag 1055613)

Ok, dann sind die Buttons vielleicht doch überflüssig!?

Vielleicht noch etwas dreckiger: :-D
Du könntest die Position beim Zeichnen der Zellen ermitteln. Entweder hast Du Direkt ein Feld mit einer "RecordNummer" oder Du prüfst (wenn Du einen eindeutigen Sortwert hast) mit einem SQL-Select, ob bei der letzten Grid-Darstellung der erste oder letzte Datensatz gezeichnet wird/wurde.

Sorry, aber : ?????

[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.

[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:

Zitat von GHorn (Beitrag 1055617)

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:

Zitat von Sir Rufo (Beitrag 1055622)

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:

Zitat von Bummi (Beitrag 1055632)

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 :wink:

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.

Delphi-Quellcode:

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:

Zitat von stahli (Beitrag 1055637)

Ich will mal die Fragezeichen noch aufklären :wink:

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.

Delphi-Quellcode:

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:wink: : 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 :zwinker:

[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:

Zitat von GHorn (Beitrag 1055698)

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

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