DBGrid und Touchscreen

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

Hi, shönen Dank für deine Meinung. Hast Recht: Die Entwicklung dauert wirklich lange(ist auch nicht meine erste Version, sondern inzwischen V2 Intermediate. Weil es eine Intermediate ist kann ich leider im Moment auch nicht die BDE rauswerfen. Die BDE funktioniert unter Win7 im XP Kompatibilitätsmodus immer noch ganz gut.
Leider sind gerade solche Probleme mit dem Scrollen DIE Probleme, die vom Kunden gerne mal gemeldet werden und an denen man besonders lange "rumfummeln" muss bis auch die letzten Feinheiten funktionieren.

Hast du mal ne URL, wo man euere Produkte bewundern kann?

[Neumann]

Hallo,

klar habe ich so etwas. Hier ist ein z.B. Link zu einer Demoversion: http://www.es-kassen.de/PicassoGastronomieSetup.exe

Ja noch was zu den Kunden: Die finden immer etwas, was man "noch besser" machen könnte, und gerade manche "Kleinigkeiten" machen dann oft die allergrößte Mühe, ich kenne das auch. Andererseits kommt man ohne die Anregungen der Kunden auch nicht wirklich weiter.

Gruß

Ralf

[noisy_master]

Zitat von Neumann:

Hallo,

klar habe ich so etwas. Hier ist ein z.B. Link zu einer Demoversion: http://www.es-kassen.de/PicassoGastronomieSetup.exe

Ja noch was zu den Kunden: Die finden immer etwas, was man "noch besser" machen könnte, und gerade manche "Kleinigkeiten" machen dann oft die allergrößte Mühe, ich kenne das auch. Andererseits kommt man ohne die Anregungen der Kunden auch nicht wirklich weiter.

Gruß

Ralf

Jupp ist ganz hübsch, wobei auch an einigen Stellen etwas überfrachtet(z.B. Einstellungen) Da hat dann der gemeine Restaurantbesitzer schon seine Schwierigkeiten das zu finden, was er ändern möchte. Die meisten davon sind IMHO erst nach 5-7 Jahren dazu in der Lage ihr Programm so einzustellen, wie sie es eigentlich haben wollen

[Sir Rufo]

Darum gibt es bis dahin ja auch "Betreutes Einrichten".

[Neumann]

Ja, hast recht.

Die Einstellungen müssen dringend aufgeräumt werden. Ich bin dabei dies und auch einige Auswertungen von der Kasse zu trennen; wird aber noch etwas dauern. Der einfache Gastronom braucht auch vieles nicht, aber jeder braucht etwas anderes, so sind im Laufe der Jahre die vielen Möglichkeiten das Programm zu konfigurieren dazugekommen. Übrigens gibt es noch mehr Optionen als wie man auf den ersten Blick sieht.

Hast du auch eine Demoversion?

Gruß

Ralf

[stahli]

Für eine solche Anwendung würde ich den Einsatz eines "billigen" DBGrid eher vermeiden und auf eine objektbasierte Anzeige setzen.
So kann man sich die Darstellung und Bedienung optimal für den jeweiligen Zweck selbst erstellen.
Wenn es dann noch grafisch ansprechend ist, um so besser.

Das kann man dann z.B. durch Panels in einer Scrollbox lösen. Jedes Item representiert einen Datensatz aus der Datenbank und ist bis zur nächsten Abfrage gültig. (Anbei mal ein Bild aus meinem Projekt - wobei ich aktuell keine Skins mehr verwende.)

Also eher IPhone-Feeling als DBGrid.

[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