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.
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)
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)
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 (
Daten
bank
management
system), 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.
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.
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.