DiLi-Tech

Terminkalender

Mein Terminkalender hat eine laaange Geschichte...

Alles fing Anfang 1990 an mit einem selbstgeschriebenen ATARI ST-Programm - vollständig in GEM, also die grafische Benutzeroberfläche - eingebunden. Die war recht aufwändig zu programmieren, da alle GUI-Ereignisse in einer selbstgeschriebenen Ereignisschleife abgefragt und entsprechend behandelt werden mussten. Also z.B.: da ist ein rechteckiger Bereich des Bildschirmes ungültig - darüber liegendes Fenster verschoben - und muss daher neu gezeichnet werden... In Pascal geschrieben. Die GEM-Bibliotheken wurden nicht mitgeliefert, also habe ich diese Bibliotheken selbst geschrieben...

Der Terminkalender war anfangs eine reine Einzelplatz-Anwendung. Die lief so einige Jahre. Und dann kam Windows 95, es wurde ein PC angeschafft und der ATARI wurde aufs Abstellgleis geschoben. Meinen Terminkalender habe ich auf dem neuen Windows-PC mit einer ATARI-Emulation am Leben erhalten.

Bis ich mich Jahre später entschloss, den Kalender auf die Windows-Plattform zu portieren. Dann aber sofort so, dass die Datenbasis auf dem inzwischen eingerichteten Home-Server abgelegt werden konnte. Darauf konnten später alle Familien-PCs mit Kalender zugreifen.

Programmiert wurde in Delphi, die objektorientierte Weiterentwicklung von Turbo-Pascal der Firma Borland. Damit war die GUI-Programmierung um Größenordnungen einfacher als seinerzeit auf dem ATARI. Überhaupt war Delphi seinerzeit sehr beliebt, dank der tollen IDE (Integrated Development Environment). Die unter Delphi erstellten Windows-Binaries sind heute noch unter Windows 7 lauffähig - ist halt ein richtiges Win-32-Programm!

Inzwischen (2015) kann ich auf 25 Jahre Terminkalender zurückblicken mit einer Datenbasis ab 1990. Ich kann also z.B. nachschauen, in welchen Kinofilmen ich in 1991 war... Wer kann das schon - mal ehrlich!

Heute sind "Cloud-Services" in aller Munde und der reinste Hype. Das hatte ich schon Jahrzehnte vorher... Mit dem damals aufkommenden Internet kamen auch die Dyn-DNS-Dienste. Auf dem heimischen Server lief inzwischen ein Webserver für die private Homepage - die man unbedingt haben musste. Diese konnte über eine Dyn-DNS-Adresse weltweit aufgerufen werden. Was lag also näher, als dem Terminkalender ein Web-Interface zu spendieren.

PHP 4 war seinerzeit aktuell und damit habe ich das Webinterface des Kalenders geschrieben. Inzwischen auf PHP 5 portiert... Mit dem Web-Terminkalender in der heimischen "Cloud" konnte ich seinerzeit vom Büro-PC nachschauen, ob meine liebste aller Ehefrauen abends schon wieder mit ihren Freundinnen unterwegs war...

Das also zu Zeiten, als es noch keine Smartphones mit Kalender-Apps gab. Und Google war nur eine reine Suchmaschine, Android und iPhones noch völlig unbekannt!

Die Highlights des Kalenders sind:

  • der Kalender zeigt auf einen Blick die Belegung mit Terminen, Feiertagen, Zeitspannen
  • ein Klick öffnet ein entsprechendes Listenelement für den Tag
  • Sie können beliebig viele Tageslisten öffen
  • mittels Drag and Drop können Termine verschoben werden
  • Sie können mittels aufgezogenem Rahmen z.B. alle Termine einer Woche oder der nächsten Wochenenden einsehen
  • Sie können jedem Termin ein individuelles Erinnerungsintervall zuordnen. Das Erinnerungsmodul "REMINDER" wird dann entsprechend vorher an diesen Termin erinnern
  • Sie können zu einem Termin beliebig lange Memos vermerken
  • Ebenso ist es nun möglich, bestimmte - oder alle - Termine zu verschlüsseln
  • Es gibt eine Textsuche, die sowohl den Terminnamen als auch die Memos einbezieht
  • alle Feiertage sind bekannt
  • Sie können monatlich- und jährlich-periodische Termine verwalten
  • Für andere periodische Termine existiert ein komfortabler Termingenerator (z.B. jeder 3. Freitag alle 2 Monate)
  • Die Datenbank kann sich auf einem Netzlaufwerk befinden - so können mehrere Personen auf die Termine zugreifen - auch gleichzeitig
  • Es existieren Import-, Export- sowie Datensicherungsfunktionen
  • Auch eine einfache Adressverwaltung ist vorhanden
  • Es existiert ein Web-Interface, sodass auch aus der Ferne per Browser auf die Termine und Adressen zugegriffen werden kann - einen eigenen Webserver vorausgesetzt. Am besten in Form eines ständig laufenden Rechners zuhause und per Dyn-DNS von ausserhalb erreichbar. Die Funktionen des Web-Kalenders sind gegenüber den Funktionen der Windows-Anwendung leicht eingeschränkt - "AJAX" war noch nicht erfunden und aktuell scheue ich den Aufwand, etwas nachzurüsten...

Spielen Sie doch einmal mit dem Demo-Online-Kalender (oben).

[Update (10/2021)] Es hat sich ergeben, dass ich mich in die PC-Programmierung wiedereinarbeiten muss. Das letzte PC-Software-Projekt liegt tatsächlich schon länger als 1 Jahrzehnt zurück (!)... Da ich in der Zwischenzeit mich mit ganz anderen Themen beschäftigt habe, ist da ziemlich viel "verschütt' gegangen". Glaubte ich zunächst. Durch meine Beschäftigung mit meinem aktuellen SmartHome-Projekt (siehe: Alarmanlage) besteht nun die Notwendigkeit, Letzteres mit einem PC zu koppeln. Dazu bedarf es eines maßgeschneiderten Kommunikations- und Konfigurationsprogrammes. Das muss ich selbst erstellen. Au au, keine Ahnung mehr.

Frage: wie kommt man am Schnellsten (zurück) in ein Thema? Ja: machen! Also habe ich ein 20 Jahre altes Projekt hervorgekramt und mich daran abgearbeitet.

Die erste PC-Version vom Terminkalender hatte ich in Delphi programmiert. Angefangen mit der Delphi-Version 3, später dann 5 und 6. Die uralte Delphi-6-Umgebung (von 2001) läuft tatsächlich noch - auf einem Uraltrechner mit Windows-XP. Steht als Museumsstück in einer Ecke. Darin habe ich "herumgestöbert" und gedacht, wie schade es doch ist, dass das so 'rumliegt.

Und nun ist es so, dass das Programm heute noch tagtäglich benutzt wird. Darin lagern inzwischen (quittierte) Termine von fast 30 Jahren. Es hat so die Funktion eines Tagebuchs bekommen. Es arbeiten mehrere PCs gemeinsam auf einer Datenbasis. Auch das Web-Interface wird täglich benutzt.
Nachsatz: Es hat in dieser langen Zeit NICHT EINEN Fall von Datenverlust oder korrumpierten Daten gegeben!!

Fig. 1: Der (neue) Terminkalender!

Aber man kann doch so schön seine Termine im Smartphone-Kalender pflegen... ? Na besser nicht! Google weiß auch so schon zuviel über seine (Android-) Nutzer. Da werfe ich nicht noch sensible Daten hinterher in den Rachen einer Datenkrake. Sie glauben doch nicht, dass Ihre geheimen Daten dort geschützt sind. Auf Android? Ha!!

Also: ich habe mir die aktuelle Version der (fast Delphi-kompatiblen) Object-Pascal-IDE "Lazarus" herunter geladen (Version 2.012). Und als Erstes versucht, die alten Terminkalender-Sourcen nach Lazarus zu konvertieren. Es gibt in Lazarus einen Menüpunkt, der Delphi-Projekte umwandeln können soll. Na jedenfalls hat das zunächst nicht so richtig funktioniert. Schade.

Fig. 2: Die Termine-Verwaltung. Mit beliebig langen (dynamisch verwalteten) Memos

Es hagelte hunderte von Fehlermeldungen. Verstanden habe ich nichts. Eigentlich kein Wunder. Danach habe ich Schritt für Schritt (kleine!) mir Lazarus anhand von ebenfalls kleinen Beispielen erschlossen. Und in den alten Delphi-Büchern geblättert. Um dann das Portierungs-Projekt durchzuziehen. Nach 4 Wochen steht nun eine neue, aufgehübschte, fehlerbereinigte und erweiterte neue Version des Kalenders bereit - puh!

Und ich bin wieder fit. Es ist erstaunlich, was alles zum Vorschein kommt, wenn man sich damit wieder beschäftigt. Inzwischen ist es so, als hätte ich nie etwas anderes getan. Und ich kenne ganz viele Interna von Lazarus.

Fig. 3: Kontakte-Verwaltung (Kontakte können von Terminen verknüpft werden)

Fazit zu Lazarus: Es ist ein ziemlicher Moloch, unübersichtlich; da tummeln sich alte Überbleibsel neben neuen Units. Und viele Erweiterungen, die man erst einmal finden muss. Das "neumodische" UTF8 macht es nicht einfacher...(!) Das Hilfe-System ist teilweise beispielhaft, teilweise grottig. Es gibt noch Probleme bei der deutschen Lokalisierung: da erscheinen Standard-Dialoge, die statt "Abbruch" dann "Cancel" ausgeben (Tipp: Interessierte sollten 'mal in die Datei "lclstrconsts.pas" im Unterordner "\lcl\" schauen; dort habe ich die englischen Stringkonstanten eingedeutscht und voilà: Schluss mit "Cancel" und Co...).

Mein aktuelles Fazit ist trotzdem positiv: Nach Jahrzehnten ist Lazarus den Kinderschuhen entwachsen und eine ausgezeichnete Alternative zu Delphi von Embarcadero, ursprünglich Borland. Es gibt eine rührige Community und viele Erweiterungs-Komponenten. Alles kostenlos!!!! Ich habe es nicht bereut, mich damit beschäftigt zu haben. Aber Schluss jetzt. [/Update]

Zur "Installation": Sie entpacken das Zip-Archiv z.B. nach c:\terminkalender\. Danach erstellen Sie eine Verknüpfung auf dem Desktop. Eine modifizierte Verknüpfung mit "c:terminkalender\terminkalender.exe /reminder" können Sie in den Autostart-Ordner schieben; dann wird bei jedem Rechnerstart das REMINDER-Modul gestartet.

Zur Bedienung: gehen Sie über "Notizen/bearbeiten..." zur Notizfunktion und schauen Sie sich die Erläuterungen an.

Hinweis für Win10/11-Benutzer: die "normalen" Programmverzeichnisses verwenden Sie bitte nicht! Der Terminkalender schreibt seine Einstellungsdaten und zunächst seine Datenbasis in sein Programmverzeichnis. Ab Windows-Vista ist das im Standard-Programmverzeichnis verboten (Stichwort: Virtualisierung). Deshalb müssen Sie ausweichen.

Den Download gibt es hier. Das Programm nimmt keinerlei Änderungen außerhalb des eigenen Programmverzeichnisses vor. Zur Deinstallation reicht das Weglöschen des Ordners.
Sie möchten den Quellcode (PHP 7.4) des Web-Interfaces haben? Dann mailen Sie mich kurz an!

Es gibt neben mir auch noch andere Zeitgenossen, die Ihre Finger nicht von alter, bewährter Soft- und Hardware lassen können. Hier ein Beispiel für den jahrzehntelangen Betrieb einer ATARI-Software!

 

PS: Ich muss doch noch etwas sagen... DAS wird aber wohl nur die Software-Spezies unter Ihnen interessieren! Zu den Problemen, die sich durch die gezwungene Umstellung auf UTF8 ergeben haben. Für die Portierung alter Deplhi-Anwendungen wäre es schön, wenn es in Lazarus einen zentralen Schalter für "UTF8 ein" bzw. "UTF8 aus" geben würde! Das hätte mir eine Menge Arbeit und Zeit erspart und die Nerven geschont.

Letztendlich habe ich dann doch noch Schalter gefunden, mit denen sich UTF8 in Editor und Compiler abstellen lässt. Es wäre schön gewesen, wenn bei der automatischen Konvertierung der alten Delphi-Sourcen ins Lazarus-Format vom System auf diesen Modus hingewiesen worden wäre... Ansonsten kann es bei der Bearbeitung von UTF8-Strings zu recht unerwarteten Effekten kommen.

Einige der alten so vertrauten Bibliotheksfunktionen kommen mit UTF8 häufig nicht zurecht. Da heißt es: ausprobieren. Oder die neuen Pendants nehmen. Wenn man sie denn findet (Tipp: mal in die "lazUTF8"-Unit schauen!). UTF8-Strings haben die unangenehme Eigenschaft, dass z.B. deutsche Umlaute nicht mehr mit EINEM Byte codiert werden sondern in Multibyte dargestellt werden (Umlaute: 2). Dafür sind aber alle internationale Zeichen verarbeitbar - einschließlich Emojies.

Ich mache das Problem mal deutlich: nehmen wir einen String mit fester Länge:
Type zeile: string[80]; . Da passen also 80 Zeichen hinein.

Nee, leider nicht. Sobald z.B. ein Umlaut darin enthalten ist - der 2 Byte Platz benötigt - passen nur noch 79 Zeichen hinein. Bei jedem weiteren Mehr-Byte-Zeichen verkürzt sich die "Kapazität" noch weiter. Ein Windows-Control (z.B. ein Edit-Feld) lässt aber weiterhin genau z.B. 80 Zeichen zu... Was passiert, wenn der Umlaut ganz am Ende steht???? Der 2. Teil des Zeichens fehlt und es entsteht Murks!

Beispiel 2:
var s:string; ... s:='aä';. Sollte eindeutig sein - oder?
UTF8Length(s) liefert: 2
length(s) liefert: 3
Preisfrage: was liefert var c:char; ... c:=s[2]; ??? Ja: Murks!
Wenn Sie einen reinen ASCII-Editor verwenden, NUR dann liefert length(s) ebenfalls 2.
Abhilfe: Verwendung von UTF8Copy(s,2,1). Mit copy(s,2,1) gibt es??? Ja: Murks!

Bei meiner Portierung hagelte es nur so Probleme mit den Umlauten. Mal wurden sie korrekt dargestellt, mal als "?", mal als kryptische 2-Zeichen-Folge... In einem Nebensatz an irgendeiner Stelle der umfangreichen Dokumentation wurde erwähnt, dass sich folgende Definition machen lässt:
Type meinStringTyp = TYPE STRING(1252). "1252" ist die Codepage von Windows (in Mitteleuropa). Damit definiert man 1-Byte-Zeichen mit dem Zeichensatz von Windows. Eben jenen, den auch das alte Delphi verwendete. Und sie sind zuweisungskompatibel zu UTF8-Variablen. Da wird in beiden Richtungen automatisch vom Compiler hin- und her- ge"castet", z.B.: UTF8Var := Var1252; . Und umgekehrt. Perfekt!

Ich habe den neuen Stringtyp stringCP genannt. CP als Anlehnung an die CodePage (von Windows). Die Gewissensfrage, "stringCP" zu verwenden oder bei Lazarus die UTF8-Off-Schalter zu setzen, also nicht die Standard-Einstellungen zu verwenden - dabei werden ALLE Runtime-Bibliotheken neu kompiliert - habe ich für mich zu Gunsten von "stringCP" beantwortet. Ich glaube, das ist das kleinere Übel.

Im folgenden Kasten habe ich notiert, was ich für mich als sehr hilfreich erfahren habe:

type stringCP = TYPE STRING(1252); Merke: zwischen string- und stringCP-Variablen wird durch Zuweisung in beide Richtungen automatisch ge"castet"! Probleme gibt es beim string[1..n]. Der kann sowohl UTF8 als auch CP sein! Lösung: IMMER mit string[] := stringCP( utf-string ) und utf-string := WinCPtoUTF8( string[] ) direkt casten! oder: string[] := stringCP und stringCP := string[] Damit bleibt string[] AUSSCHLIEßLICH ein 1Byte-Zeichensatz-String Probleme auch bei direkter Zuweisung von 'äöüß'-"Konstanten" (wegen UTF8-Editor!) zu stringCP-Vars! Und auch bei der Zuweisung an CHAR-Variablen. Lösung: UTF8-Zwischenvariable nutzen - oder den Editor in den ASCII-Modus umschalten. Probleme auch beim Anhängen bei stringCP + ' ' : da passiert Mist äöüß -> ???? Vmtl.auch beim Konkatenieren mit anderen Stringkonstanten..., nicht bei Variablen! Mein Fazit: "Alt"-Anwendungen auf stringCP umstellen, den Weg zu UTF8 aber offen halten.

nach ganz oben

     Kommentieren Sie hier!