Moin,

jetzt wo ich mich nach langer Zeit mal wieder Delphi zuwende,
möchte ich es auch richtig/besser machen.

Das was mir so noch an umzusetzende Gedanken im Kopf rumschwirrt,
will ich diesmal auch versuchen alles richtig/besser zu machen.

Was gehört alles zu einem Windows Programm:
- Ein Installer?
- Eine Hilfedatei
- Mehrsprachigkeit
- die Fähigkeit des Programmes Einstellungen zu speichern z.B. in der
Registry.
- Eine Menüleiste?
- Eine Statusleiste?

Wie sollte man den Quelltext gestalten:
- Möglichst nur ein Aufgabe pro Procedure/Funktion
- Erklärende Kommentare im Kopf einer Procedure/Funktion und bei Schleifen
- Bei JEDER Eingabe davon ausgehen, das es nicht geplant Eingaben gibt und
diese abfangen
- Bei jeder Ausgabe damit rechnen das das Zielmedium/-gerät nicht verfügbar
ist.

Was habe ich noch vergessen?

MfG
Heiko

Heiko Rompel schrieb:

> Wie sollte man den Quelltext gestalten:
> - Möglichst nur ein Aufgabe pro Procedure/Funktion

Lokale (Einmal-)Prozeduren verwenden, zur Erhöhung der Übersichtlichkeit
(Abhängigkeiten).

> - Erklärende Kommentare im Kopf einer Procedure/Funktion und bei Schleifen

Ich fange mit einem Gerüst aus Kommentaren an, das anschließend mit Code
gefüllt wird.

> - Bei JEDER Eingabe davon ausgehen, das es nicht geplant Eingaben gibt und
> diese abfangen

Kommt drauf an. Oft ist es besser, Eingaben erst dann (im Zusammenhang)
zu prüfen, wenn eine Aktion ausgeführt werden soll.

> - Bei jeder Ausgabe damit rechnen das das Zielmedium/-gerät nicht
> verfügbar ist.

Höchstens bei lebenswichtigen Ausgaben. Dummuser werden nicht klüger
wenn man ständig versucht, ihnen das Denken und die Verantwortung für
ihren Unsinn abzunehmen. Ich unterscheide da zwischen Auftragsarbeiten,
bei denen ich mich nach den Vorgaben des Auftraggebers richte, und
eigenen Projekten, bei denen ich mir Dummuser (AKA Problembären ;-)
durch das Weglassen von verzichtbarem Zucker vom Halse halte.

> Was habe ich noch vergessen?

Sicher, aber wir wollen ja kein Buch schreiben ;-)

<Eigentlich> sollte man mit der Dokumentation anfangen, nicht mit dem
Codieren.
</eigentlich>

Daneben scheint mir eine ordentliche Modularisierung wichtig, mit
Trennung von Oberfläche und Ausführung (etwa Model-View-Controller).

DoDi

Heiko Rompel <noreply@heiko-rompel.de> schrieb:
> Moin,
>
> jetzt wo ich mich nach langer Zeit mal wieder Delphi zuwende,
> möchte ich es auch richtig/besser machen.
>
> Das was mir so noch an umzusetzende Gedanken im Kopf rumschwirrt,
> will ich diesmal auch versuchen alles richtig/besser zu machen.
>
> Was gehört alles zu einem Windows Programm:
> - Ein Installer?

Wenn das Programm aus _so_ vielen Dateien besteht... im Normalfall
reicht ein ZIP-Archiv aus. Ein Installer ist ein Programm, dass
eigentlich bloß prüfen soll, ob die benötigten DLLs da sind, und wenn
nicht, sie ins Windows-Verzeichnis zu packen. Sie im
Programmverzeichnis zu behalten, reichte zwar auch aus, aber egal...

Ein Uninstaller wäre gut, wenn noch Reg-Keys da sind, die gelöscht
werden sollten, wenn das Programm gelöscht wird. Aber von der Reg
halte ich i.A. eh nicht viel...

> - Eine Hilfedatei

Wenn das Programm so gemacht ist, dass es sich nicht von selbst
erklärt, ja. (Wenn man beispielsweise nur den Binomialkoeffizienten
zweier Zahlen berechnen lassen will, und es zwei Eingabefelder gibt
und ein drittes, wo das Ergebnis reinkommt, gibt es nicht viel zu
erklären. Wer nicht weiß, was ein Binomialkoeffizient ist, dem nützt
das Programm eh nicht viel.)

> - Mehrsprachigkeit
> - die Fähigkeit des Programmes Einstellungen zu speichern z.B. in der
> Registry.
> - Eine Menüleiste?
> - Eine Statusleiste?

Wenn es sein muss... ich behaupte: Je einfacher, desto besser. Oben
erwähntes Programm braucht zwei Zahlen als Eingabe und ein
Ausgabefeld. Braucht man da eine Statuszeile? Was sollte man
reinschreiben? Ein Menü? Einstellungen? Wozu?

Aber es gibt kompliziertere Projekte, die da schon mehr benötigen
dürften.

Und wenn Einstellungen: Wo lieber speichern: In der Registry, dem
großen Dunghaufen, wo jeder nach seinem Gutdünken reinkackt, oder in
eine .ini oder .cfg, die in den entsprechenden Profilordnern der
Benutzer liegt?

>
> Wie sollte man den Quelltext gestalten:
> - Möglichst nur ein Aufgabe pro Procedure/Funktion

Hm... definiere "Aufgabe": "Addiere zwei Zahlen" oder "Verarbeite die
Eingabe"? Ersteres ist IMHO zu simpel für eine eigene Prozedur,
letzteres eventuell zu kompliziert.

> - Erklärende Kommentare im Kopf einer Procedure/Funktion und bei Schleifen

Vor jeder Routine, OK. Aber wieso vor Schleifen? Wichtig ist auch, das
"Warum?" zu erklären, nicht das "Wie?", das steht da.

> - Bei JEDER Eingabe davon ausgehen, das es nicht geplant Eingaben gibt und
> diese abfangen
> - Bei jeder Ausgabe damit rechnen das das Zielmedium/-gerät nicht verfügbar
> ist.
>

Das muss man ja eh.

> Was habe ich noch vergessen?

_Übersichtliches_ Layout. Nicht möglichst viel auf ein Formular..
Eventuell gleich mehrere Formulare einplanen. Jedenfalls erst planen,
dann schreiben (das schreibt sich bedeutend besser). Auch im Zeitalter
von OO ist "Teile und Herrsche" kein schlechtes Prinzip (OO baut ja im
Prinzip auch darauf auf).

Backend und Frontend voneinander trennen. Das Frontend breitet
lediglich die Eingaben für das Backend auf. Das Backend arbeitet.

>
> MfG
> Heiko
>

Tschö,
Markus
--
Nur weil ein Genie nix reißt, muß ja nun nicht gleich jeder Idiot
pausieren... Bully hats ja auch geschafft.
-- gUnter nanonüm in de.alt.anime

Markus Wichmann schrieb:
>>
>> - Ein Installer?
>
> Wenn das Programm aus _so_ vielen Dateien besteht... im Normalfall
> reicht ein ZIP-Archiv aus. Ein Installer ist ein Programm, dass
> eigentlich bloß prüfen soll, ob die benötigten DLLs da sind, und wenn
> nicht, sie ins Windows-Verzeichnis zu packen. Sie im
> Programmverzeichnis zu behalten, reichte zwar auch aus, aber egal...

Kommt IMHO auf die Zielgruppe an. Ein DAU kann mit einem ZIP nicht
beliebig viel anfangen - ok, seit WinXP ist der "Entpacker" zwar
im OS (per virtuellem "ZIP-Ordner") integriert, und vielleicht kann
der Anwender dann noch die entpackten Dateien per Explorer-Drag-and-
Drop in ein ihm genehmes Verzeichnis kopieren, aber spätestens wenn
er das Dings dann über Start-Programme-... ausführen können will,
hörts auf. Und den Anwender dann vielleicht noch COM-Kompontenten
per REGSRV32 selber installieren lassen, kann man dann IMHO schon
niemandem mehr zumuten.

Außerdem finde ich es auch hübsch konsistent, wenn man ein Programm
per Start-Einstellungen-Systemsteuerung-Software-Entfernen wieder
wegkriegt - und das geht eben nicht, wenn man zur "Installation"
nur ein ZIP entpackt hat.

Das Installshield-Express, das Delphi beiliegt, kann das eigentlich
schon alles recht gut. Mit ein bißchen Tricks kann man beim
Installieren und Deinstallieren auch eigene Programme ausführen
(z.B. die Installation eines Firebird-Servers als Dienst), wofür
man "eigentlich" die IS-Vollversion bräuchte. Jedenfalls hatte ich
nie den Bedarf, auf die Vollversion upgraden zu müssen.

Gruß Matthias.

Hallo Matthias,

Matthias Hanft schrieb:

>> Wenn das Programm aus _so_ vielen Dateien besteht... im Normalfall
>> reicht ein ZIP-Archiv aus. Ein Installer ist ein Programm, dass
>> eigentlich bloß prüfen soll, ob die benötigten DLLs da sind, und wenn
>> nicht, sie ins Windows-Verzeichnis zu packen. Sie im
>> Programmverzeichnis zu behalten, reichte zwar auch aus, aber egal...
>
> Kommt IMHO auf die Zielgruppe an. Ein DAU kann mit einem ZIP nicht
> beliebig viel anfangen

Mein erster Einsatz eines Installers kam deshalb weil ich mir nicht merken
wollte, wo wer das Programm beim letzten Mal hinkopiert hat. Das ist dann
bei Updates ein Problem. Der Installer nimmt mir die Sorge ab und schlägt
das richtige Verzeichnis vor.


> man "eigentlich" die IS-Vollversion bräuchte. Jedenfalls hatte ich
> nie den Bedarf, auf die Vollversion upgraden zu müssen.

Ich auch nie, aber das habe ich dem wunderbaren Produkt "Inno-Setup" zu
verdanken. :-)


Gruß, Joe
--

Joe Galinke schrieb:
>
> Mein erster Einsatz eines Installers kam deshalb weil ich mir nicht merken
> wollte, wo wer das Programm beim letzten Mal hinkopiert hat. Das ist dann
> bei Updates ein Problem. Der Installer nimmt mir die Sorge ab und schlägt
> das richtige Verzeichnis vor.

Stimmt, das mit den Updates ist auch noch ein Argument. Und "Ändern" /
"Reparieren" über die Systemsteuerung...

[InstallShield-Vollversion nicht nötig]
> Ich auch nie, aber das habe ich dem wunderbaren Produkt "Inno-Setup" zu
> verdanken. :-)

Ja, das habe ich auch mal ausprobiert - und bin von den tausend Optionen
und Einstellungen "erschlagen" worden. Sicher ist das total leistungs-
fähig (und besser/schöner/größer/kostenloser als InstallShield), aber
ich hab' einfach nicht die Zeit, mich da einzuarbeiten. Bei IS-Express
kann man ja einfach von oben nach unten alle nötigen Punkte abhaken und
schließlich F7 drücken - das ist so schön einfach wie ich's brauche :-)

Gruß Matthias.

Hallo Matthias,

Matthias Hanft schrieb:

> Ja, das habe ich auch mal ausprobiert - und bin von den tausend Optionen
> und Einstellungen "erschlagen" worden. Sicher ist das total leistungs-
> fähig (und besser/schöner/größer/kostenloser als InstallShield), aber
> ich hab' einfach nicht die Zeit, mich da einzuarbeiten.

Ich habs geschafft und es geht wirklich. :-) Mit ISTOOL hat man dann noch
eine Oberfläche, die es einem deutlich vereinfacht. Ich nutze sie häufig
wenn mir irgendeine Syntax nicht einfällt oder bekannt ist.

Gruß, Joe
--

Markus Wichmann schrieb:

> Und wenn Einstellungen: Wo lieber speichern: In der Registry, dem
> großen Dunghaufen, wo jeder nach seinem Gutdünken reinkackt, oder in
> eine .ini oder .cfg, die in den entsprechenden Profilordnern der
> Benutzer liegt?

Und hier sollte ein Installer die ganzen Verzeichnisse anlegen. Früher
war es einfach, da hielt man die INI Datei im Programmverzeichnis. Heute
ist dieses Verzeichnis schreibgeschützt, wenn es im
Windows-Programmverzeichnis liegt, und für die Installation und jeden
Benutzer müssen dann die dafür vorgesehenen Verzeichnisse angelegt
werden. Und im Programm müssen die natürlich auch benutzt werden.

Für rein private Programme, die garnicht im Windows-Programmverzeichnis
landen, kann man sich natürlich einen Installer sparen.


> _Übersichtliches_ Layout. Nicht möglichst viel auf ein Formular..
> Eventuell gleich mehrere Formulare einplanen. Jedenfalls erst planen,
> dann schreiben (das schreibt sich bedeutend besser). Auch im Zeitalter
> von OO ist "Teile und Herrsche" kein schlechtes Prinzip (OO baut ja im
> Prinzip auch darauf auf).
>
> Backend und Frontend voneinander trennen. Das Frontend breitet
> lediglich die Eingaben für das Backend auf. Das Backend arbeitet.

Du meinst wohl die Trennung von Oberfläche (Forms) und Arbeitsteil
(Units). Die ist bei jedem nicht so ganz trivialen Programm sinnvoll,
d.h. auch schon dann, wenn mehr als 1 Form beteiligt ist. Dann enthalten
die Units die gemeinsam benutzten Daten und Funktionen.

Man kann die Systematik noch weiter treiben, mit einer Unterteilung in
Model, View und Controller, wobei "Model" typischerweise Datentypen
enthält, "View" sind die Forms, und "Controller" soll wohl die Klassen
oder Prozeduren, welche die gespeicherten Daten vor unbefugten Zugriffen
schützt und die Konsistenz der Daten sicherstellt. Wenn man mit Klassen
arbeitet, können die gleichzeitig als Model und Controller betrachtet
werden. Oder habe ich da was falsch verstanden?


Eine Aufteilung in mehrere Units hat für mich noch einen ganz
wesentlichen Vorteil: ich kann gleichzeitig die Implementierung und die
Verwendung der Funktionen auf dem Bildschirm haben. Oder die Deklaration
(einer Klasse) im einen und die Implementierung der Methoden im anderen
Fenster. Bis D7 war das noch einfach zu bewerkstelligen, neuerdings muß
man dazu AFAIK erst das SDI-Layout abwählen, und dann darauf hoffen, daß
die Fehler in der Verwaltung mehrerer Code-Fenster inzwischen behoben sind.

Im Kontext-Menü eines Editor-Fensters gibt es dazu sowas wie "In neuem
Fenster öffnen", dann wird für die aktuelle Datei ein weiteres Fenster
geöffnet, in dem man unabhängig Scrollen kann. Dazu ist es auch noch
sinnvoll, alle Units in das Projekt einzufügen, dann kann man im
Projekt-Manager jede benötigte Unit im gerade aktiven Editor-Fenster
öffnen lassen.

Zusätzlich habe ich (in D7) den Object-Inspector und den Project-Manager
in ein gemeinsames Fenster (mit zwei Tabs) gelegt. Beim Hantieren an den
Forms bleibt dann der Tab mit dem Object-Inspektor geöffnet, sonst der
mit dem Projekt-Manager. Dann muß von diesem Fenster nur ein Zipfel zu
sehen sein, an dem man es bei Bedarf in den Vordergrund holen kann.

DoDi