Kalender programmieren?

[hubblec4]

Zitat von Perlsau:

Das ist ein ganz normales StringGrid(StG) bzw. das TjvStringGrid aus den Jedi-Komponenten.

Ich weis jetzt nicht genau in wie weit ich die Jedi-Komponenten in Lazarus verwenden kann, aber ist das TjvStringGrid schon ein bissl anders als das normale StringGrid?
Du hast in einer Zelle das Datum und weitere Uhrzeiten, hast du da Zellen miteinander verbunden oder wie kann man mehrere zeilen in einer Zelle darstellen... und wenn ja kannn man dann jede Uhrzeit separat anklicken(weitere Termininfos)?

Zitat von Perlsau:

Es gibt in meinem Terminator vier Ansichten auf vier TabSheets: Tages-, Wochen-, Monats- und Jahresüberblick. Zugrunde liegt eine Firebird-Datenbank, als DB-Komponenten kommt IbDac zum Einsatz, die Termintabelle sieht so aus:

Code:

CREATE TABLE TERMINE (
    IDX_TERMINE   BIGINT NOT NULL,
    BENUTZER      INTEGER DEFAULT 0 NOT NULL,
    DATUM_START   DATE,
    ZEIT_START    TIME,
    DATUM_ENDE    DATE,
    ZEIT_ENDE     TIME,
    BESCHREIBUNG  VARCHAR(200) DEFAULT '' NOT NULL COLLATE UNICODE,
    ERLEDIGT      INTBOOLEAN DEFAULT 0 /* INTBOOLEAN = INTEGER DEFAULT 0 NOT NULL CHECK (VALUE IN (0,1)) */,
    ALARMEIN      INTBOOLEAN DEFAULT 1 /* INTBOOLEAN = INTEGER DEFAULT 0 NOT NULL CHECK (VALUE IN (0,1)) */,
    ANLEGER       INTEGER DEFAULT 0 NOT NULL,
    DATUM         TIMESTAMP,
    DAUER         TIME);

Allerdings ist mein Konzept nicht wirklich ausgereift, genügt aber meinen Ansprüchen bzw. denen eines gemeinnützigen Vereins, für den ich das vor bald drei Jahren zu entwickeln begonnen hatte. Heute würde ich vieles anders angehen.

TabSheets kannte ich damals noch nicht, bei mir gibt es momentan nur das eine StringGrid was dann jeweils für die Tag oder Wochenansicht angepasst wird. Aber die Idee einer Monatsansicht gefällt mir.
Was deine Firebird-Datenbank angeht, kann ich mir das so ähnlich wie bei SQL vorstellen (Server mit SQL und dann halt SQL befehle)?
Was genau ist die IBDac Komponente(wird wohl nur bei Delphi dabei sein)?

Wenn ich jetzt meine fast 2 jahre alten SQL-Tabellen anschaue kommt mir das Grauen.

Zitat von Perlsau:

Irgendwo in deinen Ursprungsdaten, aus denen heraus du dein StringGrid befüllst, steht doch sicher die Information, die du benötigst, um die entsprechende Zelle anders einzufärben. Im Falle einer SQL-Datenbank hätte ich da eine Spalte z.B. mit dem Namen KATEGORIE oder so. Beim Abklappern der Tabelle zum Ausgeben der Werte in ein StringGrid fragst du in OnDrawCell eben einfach diese Spalte in deiner Tabelle ab und zeichnest die entsprechende Zelle dann mit der entsprechenden Farbe.

Ok, denke ich habe das soweit verstanden wie du das meinst. Ich lade die Daten aus der SQL-DB mittels eines SQL-befehls und habe dann eine SQLQuery die ich verarbeite(StG befüllen).
Jetzt ist es doch aber so das diese onDrawCell-procedure andauernd aufgerufen wird(habe da mal zum test ein SpinEdit
benutzt, SpinEdit.Value:=SpinEdit.Value+1, und nach nicht mal zwei Minute stand der zähler schon bei einer Million).
Von daher ist es nicht gut wenn der SQL-Server so oft befeuert wird.
(Der SQL-Server ist ein rechner im netzwerk auf den 6 andere rechner zugreifen)

Ich habe mir überlegt die Daten eines Tages aus der DB auszulesen und das nötigste zwischen zuspeichern, in einem array oder record, worauf eben die onDrawCell-procedure schnell zugreifen kann.

[Perlsau]

Zitat von hubblec4:

Zitat von Perlsau:

Das ist ein ganz normales StringGrid(StG) bzw. das TjvStringGrid aus den Jedi-Komponenten.

Ich weis jetzt nicht genau in wie weit ich die Jedi-Komponenten in Lazarus verwenden kann, aber ist das TjvStringGrid schon ein bissl anders als das normale StringGrid?
Du hast in einer Zelle das Datum und weitere Uhrzeiten, hast du da Zellen miteinander verbunden oder wie kann man mehrere zeilen in einer Zelle darstellen... und wenn ja kannn man dann jede Uhrzeit separat anklicken(weitere Termininfos)?

Soweit ich weiß, gibt es die Jedis nur für Delphi, nicht für Lazarus. Übrigens vermeidet man Mißverständnisse hinsichtlich der Entwicklungsumgebung, wenn man in seinem Profil die Version angibt, mit der man arbeitet.

Die mehrzeilige Darstellung hatte ich damals so erreicht, daß erstens RowHeight entsprechend vergrößert wurde und zweitens der AusgabeString (z.B. StringGrid.Cells[4,3]) aus den entsprechenden Strings, die den Termin enthielten, zusammengesetzt wurde, wobei jeder Einzelstring durch ein Chr(13) begrenzt wurde. Soweit ich mich noch erinnere, war ich damals gerade an diesem Projekt dran und habe später dieses Konzept aufgegeben. Inzwischen befindet sich unterhalb des Wochendarstellungs-StringGrids ein zweites Stringgrid mit den Terminen des gewählten Tages. Bei der Monats- und der Jahresübersicht habe ich darauf verzichtet, Einzeltermine darzustellen, sondern lediglich die Tage, an denen Termine stattfinden, gekennzeichnet.

Zitat von hubblec4:

TabSheets kannte ich damals noch nicht, bei mir gibt es momentan nur das eine StringGrid was dann jeweils für die Tag oder Wochenansicht angepasst wird. Aber die Idee einer Monatsansicht gefällt mir.

TabSheet nennt man eine Seite eines TPageControl.

Zitat von hubblec4:

Was deine Firebird-Datenbank angeht, kann ich mir das so ähnlich wie bei SQL vorstellen (Server mit SQL und dann halt SQL befehle)?

Genau. Firebird ist eine relationale SQL-Datenbank. Wobei der Server wie bei mir auch eine lokale Firebird-Installation sein kann und die Datebank nicht zwingend auf einem physikalischen Server liegen muß. Die dritte Variante wäre dann Firebird Embedded, was keine Firebird-Installation voraussetzt. Die Server-Funktionalität wird dann durch eine DLL bereitgestellt.

Zitat von hubblec4:

Was genau ist die IBDac Komponente(wird wohl nur bei Delphi dabei sein)?

Genau, das sind Datenbank-Komponenten für Firebird und Interbase, die es meines Wissens aber auch für Lazarus gibt.

Zitat von hubblec4:

Wenn ich jetzt meine fast 2 jahre alten SQL-Tabellen anschaue kommt mir das Grauen.

Das ist eine ganz normale Empfindung, wie wir sie wohl alle erleben, wenn wir uns weiterentwickelt haben.

Zitat von hubblec4:

Ok, denke ich habe das soweit verstanden wie du das meinst. Ich lade die Daten aus der SQL-DB mittels eines SQL-befehls und habe dann eine SQLQuery die ich verarbeite(StG befüllen).

Ungefähr so funktioniert das. Je nach Darstellung baust du den SQL-Befehl zusammen, so daß der Befehl immer genau die Daten selektiert, die du für die aktuelle Darstellung benötigst. Wenn du z.B. eine Wochendarstellung hast, die alle Termine sagen wir vom Montag, dem 11.01.2016 bis Sonntag, dem 17.01.2016 anzeigen soll, dann heißt das als SQL-Befehl:

Code:

select * from TERMINE where DATUM >= '11.01.2016' and DATUM <= '17.01.2016';

Oder als als Eintrag im Property Filter: DATUM >= '11.01.2016' and DATUM <= '17.01.2016', wobei die Filtered-Eigenschaft auf True stehen muß. Ich habe hier die zweite Möglichkeit gewählt, da ich die Where-Klausel im Select-Befehl des Queries bereits dafür verwende, nur die Termine des aktuellen Benutzers auszuwählen.

Zitat von hubblec4:

Jetzt ist es doch aber so das diese onDrawCell-procedure andauernd aufgerufen wird(habe da mal zum test ein SpinEdit
benutzt, SpinEdit.Value:=SpinEdit.Value+1, und nach nicht mal zwei Minute stand der zähler schon bei einer Million).
Von daher ist es nicht gut wenn der SQL-Server so oft befeuert wird.
(Der SQL-Server ist ein rechner im netzwerk auf den 6 andere rechner zugreifen)

OnDrawCell wird nur beim Zeichnen des Grids aufgerufen. Bei den heutigen Rechnern merkst du da gar nichts. Das hat nur mittelbar was mit der Datenbank und deren Zugriffsgeschwindigkeit oder mit der Bandbreite des Netzwerks zu tun. Wenn du die Filter-Eigenschaft änderst, findet kein erneuter Zugriff auf die Datenbank statt, es wird lediglich die bereits im Query befindliche Datenmenge gefiltert. Davon abgesehen ändert man nicht ständig im Sekundentakt die Darstellung. Die meisten Leute werden bei Terminkalendern wohl meist die Tagesdarstellung wählen. Beim Eintrag eines neuen Termins – was gewöhnlich auch nicht sekündlich geschieht – wird man wohl die Wochen- oder auch mal die Monatsansicht bemühen. Die Jahresansicht dient dann wohl mehr statistischen Zwecken.

Wenn dort, wo dein Programm zum Einsatz kommt, bereits ein SQL-Server existiert (gemeint ist wohl Microsoft SQL-Server), wäre es natürlich unsinnig, das jetzt mit Firebird lösen zu wollen. Hier wählst du natürlich das DBMS (Datenbankmanagementsystem), das dein Kunde bereits verwendet.

Neben der tabellenförmigen sind übrigens noch weitere Darstellungsalternativen vorstellbar, so z.B. die grafische, die einfach einen Tag oder eine Woche in Balken darstellt, wobei Termine am selben Tag z.B. hintereinander liegen. Wichtig bei Mehrbenutzersystemen ist auch, die Benutzer- und Rechteverwaltung entsprechend zu programmieren, so daß z.B. klar definiert werden kann, wer für wen Termine anlegen darf und wer alle oder nur seine eigenen Termine sehen kann usw.

Zitat von hubblec4:

Ich habe mir überlegt die Daten eines Tages aus der DB auszulesen und das nötigste zwischen zuspeichern, in einem array oder record, worauf eben die onDrawCell-procedure schnell zugreifen kann.

Wenn du ein Query hast, das deine Daten enthält, ist das bereits die benötigte Zwischenspeicherung. Es gibt Datenbank-Anwendungen auf Firebird-Basis, die mehrere hundert Benutzer gleichzeitig verkraften, da sollten sechs oder auch 20 Benutzer kein Problem darstellen.

Bei meinen Datenbank-Anwendungen wird restlos alles in der Datenbank gespeichert, auch individuelle Benutzereinstellungen wie Spaltenbreiten, Farben und Fenstergrößen und -positionen. Einzig die Art des Datenbank-Zugriffs – ob Embedded-DB, lokaler DB-Server oder Remote-Zugriff – wird entweder mit zwei drei Aufruf-Parametern geregelt oder über eine Ini-Datei.

[hubblec4]

Zitat von Perlsau:

Die mehrzeilige Darstellung hatte ich damals so erreicht, daß erstens RowHeight entsprechend vergrößert wurde und zweitens der AusgabeString (z.B. StringGrid.Cells[4,3]) aus den entsprechenden Strings, die den Termin enthielten, zusammengesetzt wurde, wobei jeder Einzelstring durch ein Chr(13) begrenzt wurde. Soweit ich mich noch erinnere, war ich damals gerade an diesem Projekt dran und habe später dieses Konzept aufgegeben. Inzwischen befindet sich unterhalb des Wochendarstellungs-StringGrids ein zweites Stringgrid mit den Terminen des gewählten Tages. Bei der Monats- und der Jahresübersicht habe ich darauf verzichtet, Einzeltermine darzustellen, sondern lediglich die Tage, an denen Termine stattfinden, gekennzeichnet.

Also ist es auch nur eine Art optische Sache die du da programmiert hattest, denn einzeln wird man die Strings in der einen Zelle nicht anklicken können?.
Denke aber auch das ich dabei bleiben werde, eine Zelle -> ein Termin.

Zitat von Perlsau:

Ungefähr so funktioniert das. Je nach Darstellung baust du den SQL-Befehl zusammen, so daß der Befehl immer genau die Daten selektiert, die du für die aktuelle Darstellung benötigst. Wenn du z.B. eine Wochendarstellung hast, die alle Termine sagen wir vom Montag, dem 11.01.2016 bis Sonntag, dem 17.01.2016 anzeigen soll, dann heißt das als SQL-Befehl:

Code:

select * from TERMINE where DATUM >= '11.01.2016' and DATUM <= '17.01.2016';

Oder als als Eintrag im Property Filter: DATUM >= '11.01.2016' and DATUM <= '17.01.2016', wobei die Filtered-Eigenschaft auf True stehen muß. Ich habe hier die zweite Möglichkeit gewählt, da ich die Where-Klausel im Select-Befehl des Queries bereits dafür verwende, nur die Termine des aktuellen Benutzers auszuwählen.

Jupp so mache ich das auch und was SQL angeht bin ich auch recht fit geworden mit der Zeit. Meine SQL Befehle sind manchmal länger als eine DINA4 seite (nicht für den Terminplaner)

Zitat von Perlsau:

OnDrawCell wird nur beim Zeichnen des Grids aufgerufen. Bei den heutigen Rechnern merkst du da gar nichts. Das hat nur mittelbar was mit der Datenbank und deren Zugriffsgeschwindigkeit oder mit der Bandbreite des Netzwerks zu tun. Wenn du die Filter-Eigenschaft änderst, findet kein erneuter Zugriff auf die Datenbank statt, es wird lediglich die bereits im Query befindliche Datenmenge gefiltert. Davon abgesehen ändert man nicht ständig im Sekundentakt die Darstellung. Die meisten Leute werden bei Terminkalendern wohl meist die Tagesdarstellung wählen. Beim Eintrag eines neuen Termins – was gewöhnlich auch nicht sekündlich geschieht – wird man wohl die Wochen- oder auch mal die Monatsansicht bemühen. Die Jahresansicht dient dann wohl mehr statistischen Zwecken.

Ich habe mal eben ein kleines Test-proggi geschrieben und war dann doch etwas erstaunt das sich das SpinEdit(SpE) nicht von alleine dauernd erhöht, sondern wirklich nur wenn man im StG etwas anklickt.
Ich weis aber das mein damaliger SpE-Test ohne das ich in dem Programm etwas angeklickt hatte erhöht hat.
Vielleicht liegt es ja an der Lazarus version wo das früher mal nicht so war.
Dennoch: bei meinem Terminplaner(habe das SpE da mal schnell reinprogrammiert) wenn man etwas anklickt
ist man ganz schnell bei mehreren tausenden aufrufen von onDrawCell und da jedes mal die Datenbank abfragen... mmh, macht mir irgendwie Bauchschmerzen. (und ja es wird sehr viel in dem Terminplaner rumgeklickt)

Zitat von Perlsau:

Wenn dort, wo dein Programm zum Einsatz kommt, bereits ein SQL-Server existiert (gemeint ist wohl Microsoft SQL-Server), wäre es natürlich unsinnig, das jetzt mit Firebird lösen zu wollen. Hier wählst du natürlich das DBMS (Datenbankmanagementsystem), das dein Kunde bereits verwendet.

ES läuft dort XAMPP mit MySQL5.5, bin damit auch recht zufrieden und es war damals für mich ein guter Einstieg in die SQL-Materie.

Zitat von Perlsau:

Wenn du ein Query hast, das deine Daten enthält, ist das bereits die benötigte Zwischenspeicherung. Es gibt Datenbank-Anwendungen auf Firebird-Basis, die mehrere hundert Benutzer gleichzeitig verkraften, da sollten sechs oder auch 20 Benutzer kein Problem darstellen.

Wenn ich den SQL Befehl abfeuer und dann die Query befüllt zurück bekomme und dann das StG befülle, dann ist meine Procedure beendet und die Query geht ja dann wieder verloren oder wird durch eine andere aktion neu befüllt, von daher denke ich ist das kein "Zwischenspeicher" in dem sinne.

Zitat von Perlsau:

Bei meinen Datenbank-Anwendungen wird restlos alles in der Datenbank gespeichert, auch individuelle Benutzereinstellungen wie Spaltenbreiten, Farben und Fenstergrößen und -positionen. Einzig die Art des Datenbank-Zugriffs – ob Embedded-DB, lokaler DB-Server oder Remote-Zugriff – wird entweder mit zwei drei Aufruf-Parametern geregelt oder über eine Ini-Datei.

Ja denke auch das es Sinn macht alles was geht an Daten in die DB zu übertragen.

[Jumpy]

Nur mal so aus Neugier. Da ja mehrere Benutzer den Kalender gleichzeitig nutzen sollen, wie hast du das mit der Aktualisierung geregelt? Wenn Nutzer A für Dienstag 9 Uhr einen Termin anlegt, wann taucht das bei Nutzer B auf dem Schirm auf?

Zur Datenhaltung werden dir viele hier empfehlen diese (wie du das planst) in einer geeigneten Struktur vorzuhalten, das ist auf jeden Fall sinnvoll. Das StringGrid oder der VST sollte dann nur der Anzeige dienen.
Du kannst dabei schon die Query zur Datenhaltung verwenden, wenn du sie nicht nur lokal in deiner "FülleMeinStringGrid" Prozedur verwendest, sondern als globales Elemet auf der Form (oder DataModul) hast. Oder du verwendest das Lazarus-Äquivalent eines TClientDatasets.

[hubblec4]

Zitat von Jumpy:

Nur mal so aus Neugier. Da ja mehrere Benutzer den Kalender gleichzeitig nutzen sollen, wie hast du das mit der Aktualisierung geregelt? Wenn Nutzer A für Dienstag 9 Uhr einen Termin anlegt, wann taucht das bei Nutzer B auf dem Schirm auf?

Da dies mein zweites Projekt war(eigentlich das erste richtige für eine Firma) und die Ansprüche anfangs sehr klein waren gabs dazu nicht wirklich eine Funktion.
Das aktualisieren der Termine bei Anwender B geschah damit, wenn er zum beispiel einen anderen Tag aufrief oder die Tagansicht in die Wochenansicht wechselt.
Später kam dann ein Button hinzu auf den die Angestellten drücken können um die Ansicht zu aktualisieren.
Ich hatte überlegt das ganze mit einem Thread mal zu automatisieren.
Desweiteren gibt es aber jedesmal eine Prüfung wenn ein Termin angelegt werden soll.
Bei Anwender A ist die Zelle noch leer, aber Anwender B hat schon einen Termin gemacht, dann bekommt Anwender A diesen Hinweis und die Ansicht aktualisiert sich und der Termin ist dann für Anwender A auch sichtbar.

Zitat von Jumpy:

Zur Datenhaltung werden dir viele hier empfehlen diese (wie du das planst) in einer geeigneten Struktur vorzuhalten, das ist auf jeden Fall sinnvoll. Das StringGrid oder der VST sollte dann nur der Anzeige dienen.
Du kannst dabei schon die Query zur Datenhaltung verwenden, wenn du sie nicht nur lokal in deiner "FülleMeinStringGrid" Prozedur verwendest, sondern als globales Elemet auf der Form (oder DataModul) hast. Oder du verwendest das Lazarus-Äquivalent eines TClientDatasets.

Ok danke, gibt mir das Gefühl doch nicht ganz blöde zu sein
Die Query als Globales Element wäre sicher auch ok, aber immer wenn ich mich belesen habe heist es, Globale Variablen seien ein schlechter programmierstil.

Bis jetzt nutze ich ein unsichtbares StG in dem ich zum Beispiel die Farben der Therapeuten ablege oder deren Level, da diese Eigenschaften oft benutzt werden, und so muss ich nicht jedesmal auf die DB zugreifen.
Denke aber das ein unsichtbares StG von der Performance her nicht unbedingt super geeignet ist.