Delphi lernen, wie vorgehen

[Paul13]

Hallo,

ich habe vor Delphi zu lernen und habe mir das Buch " Borland Delphi 7 Grundlagen, Profiwissen, Kochbuch" gekauft. Das Buch hat etwa 1.000 Seiten und ich weiß leider nicht genau wie ich vorgehen soll.

Der Grundlagen Teil umfasst etwa 300 Seiten, der Rest ist Grafikprogrammierung, Datenbank, eigene Komponenten, ... .

Ich habe das Problem, dass ich nach 200 Seiten die Inhalte der Anfangsseiten meist nicht mehr weiß, weshalb ich immer wieder die ersten Inhalte nachlesen muss. Mir kommt es vor als komme ich einfach nicht "weiter".

Könnt ihr mir eventuell ein paar Tipps geben, wie ich am besten vorgehen soll um möglichst effektiv Delphi zu lernen?

Mich würde auch interessieren wie Ihr angefangen habt?

[Angel4585]

Hallo Paul und herzlich Willkommen in der Delphi-PRAXiS!

Ich persönlich habe Delphi in der Schule gelernt.
Dort haben wir einfach drauf los programmiert.
Erst Konsolenprogramme, später VCL-Anwendungen.

Wenn die Aufgaben erledigt waren, musste immer einer am Beamer seine Lösung präsentieren und sagen, was jede einzelne Zeile genau macht.
Man kommt sich dabei etwas albern vor, aber es hat mMn geholfen das alles zu verstehen.
Besonders Wert wurde auf Formulierungen gelegt, dass die Übergabewerte für "Prozeduren" und "Funktionen" z.B. "Parameter" oder "Argumente" genannt werden.

Nachteil an der ganzen Methode: Man lernt recht wenig über generelle Programmierkonzepte.

Themen wie Design-Pattern die bei OOP wichtig sind, Versionsverwaltung und generell strukturiertes Arbeiten bleibt oft aussen vor.
Diese Dinge sind oft im nachhinein schwer zu erlernen, da man sich evtl. schon festgefahren hat.

Insgesamt würde ich dir dennoch raten einfach mal zu programmieren und zu jedem Kapital eine Beispielaufgabe zu machen.
So bleibt es wesentlich besser hängen, als wenn man nur liest.

[Paul13]

Vielen Dank für die Antwort.


Falls hier noch andere antworten würden, würde ich mich freuen

[citybreaker]

Ich habe damals mit Delphi für Kids angefangen. Ich persönlich finde das Buch auch heute noch sehr gut zum lernen und
durch das "von Kids" sollte man sich nicht abschrecken lassen.

Ein weiterer vorteil ist, dass bei dem Buch eine Vollversion von Delphi (ich glaube 7 Personal) mit bei ist.

[Der schöne Günther]

Hallo und Willkommen!

Was für Vorerfahrungen hast du? Andere Programmiersprachen? Entsteht das aus privatem Interesse?

Ich glaube jedenfalls auch nicht, dass ein normales Gehirn wirklich hunderte Seiten lesen, verstehen und alles behalten könnte - Man kann es nur, wie eben eine normale Sprache auch, nur durch Anwendung lernen. Üben, Machen, Nachdenken, verstehen, üben, machen, ...
(Ohne Stift und mit Schweigegelübde könnte man sicher auch keine Sprache lernen)


Viele Bücher und Tutorials zu Sprachen wie C quälen einen oft mit langweiliger Konsolen Ein/Ausgabe, mit Delphi kommt man ja schon ganz zu Anfang um normale Windows-Anwendungen mit Fenstern und Schaltflächen nicht herum. Ich fand das immer ziemlich motivierend, man relativ schnell etwas zusammenbauen und jemanden damit beeindrucken


Hast du einen Plan, was du auf lange Sicht umsetzen möchtest (z.B. eher Multimedia, Datenbankanwendungen, ...)? Ich hadere schon mit der Definition Delphi einmal "fertig gelernt zu haben" - Man kann mit einem Bruchteil von dem, was die Sprache Delphi bietet eine tolle Anwendung zaubern. Bleibt man weiterhin am Ball, erhält man evtl. das Wissen, das gleiche Projekt in der Hälfte der Zeit über die Bühne zu bringen. Mit mehr Praxis- und Theorieerfahrung fängt man an, seine Software so anzulegen und aufzubauen, dass sie auch in Zukunft offen für Erweiterungen ist und man mit wenig Aufwand neue Dinge einpflegen und auf Kundenwünsche reagieren kann.

Ich will nur sagen, dass man wohl mit dem Grundlagen-Teil des Buches (ich habe keine Ahnung was drinsteht) wohl sagen kann, Delphi zu können, aber es immer noch viel zu entdecken gibt, was sicher nicht schaden wird.


Ich selbst hatte meinen ersten Kontakt privat rein spaßeshalber auf einem Wochenendseminar für Delphi 4, mir hat die Sprache und Entwicklungsumgebung von Anfang an sehr gut gefallen. Ein paar Jahre später hatte ich dann nochmal neuen Kontakt zu Delphi, wieder ein paar Jahre später bin ich jetzt hier gelandet und mache Delphi von Sonnenauf- bis Untergang

[rweinzierl]

Hallo

Bei Delphi hat man im Vergleich zu anderen Sprachen sehr schnell Erfolgserlebnisse. Im Prinzip reicht es eine Schaltfläche auf die Startmaske zu ziehen einen Doppelklick auf diese und man kann code schreiben.

Dann noch auf F9 und die Anwendung läuft.

Ich habe einige Zeit gebraucht um zu verstehen warum diese Art der Programmierung (so programmieren zu lernen) zu typischen Programmierfehlern führt. Eigentlich sollte man mit Klassen, Kapselung, MVC Prinzip anfangen, aber das ist am Anfang viel zu trocken und bringt keine Erfolgserlebnisse. ( Manche Bücher versuchen es so aber die legt man nach ein paar Seiten frustriert zur Seite).

Mein Tipp, ruhig am Anfang einfach Komponenten auf eine Maske ziehen und die Eigenschaften (mit Code ) ändern. Dann aber zurück an die Theorie und versuchen zu verstehen warum in den Büchern immer wieder auf Objekt Orientierte Programmierung, Kapselung, Trennung von Programmlogik und Oberfläche, Interfaces ... eingegangen wird.

mfg

Reinhold

[Paul13]

Vielen Dank für die Antworten

@ Der schöne Günther

Ich habe keine Vorerfahrung in anderen Programmiersprachen, habe mal eine Zeit lang Webseiten mit HTML und CSS gebastelt, aber das war es auch schon wieder.

Einen konkreten Plan, was ich programmieren möchte habe ich eigentlich auch nicht nicht.
Ich wollte eigentlich erst einmal alle Grundlagen 99% drauf haben bevor ich mich um andere Dinge kümmere. Wenn ich die Grundlagen dann fehlerfrei anwenden kann, arbeite ich den Rest meines Buches durch und schaue was mich mehr oder weniger interessiert.

Also das ist zumindest der Plan.

[Medium]

An und für sich klingt das nach einer löblichen Vergehensweise, nur hat sie, wie du merkst, auch ein großes Problem: So ein Menschgehirn ist stark abhängig von der Anwendung neuem Wissens, um sich dieses auch wirklich zu verinnerlichen. Jeder etwas erfahrener Programmierer würde dir, zumindest im Affekt, zu deiner Lernidee applaudieren, funktionieren wird das in der Praxis aber leider doch eher selten.

Ich habe mit Delphi auch "quasi" angefangen. Heisst: Ich hatte mit QBASIC als Kind schon einiges gemacht, wirklich verstehen was ich tat war aber nicht drin. Es funktionierte "irgendwie", und das fühlte sich prima an. Dann ganz kurz ein Gastspiel von Turbo Pascal, dann Delphi. Die ersten Jahre waren wirklich einfaches Zusammenklicken von Komponenten, und geflissentliches Ignorieren aller guten Paradigmen der Entwicklung - oftmals auch einfach mangels Wissen um diese, und privat nicht vorhandenem Internet. (Kann sich das heute noch wer vorstellen? Ich sicherlich nicht.)
Erst nach Ende meiner Schulzeit fing bei mir so wirklich das Programmieren nach "erprobten" Vorgehensweisen an, die Sorte, wo man sich noch vor dem Schreiben etlicher Zeilen Code ernsthafte Gedanken um die Dinge gemacht hat, die man erreichen will, und welche Türen man sich noch offen halten mag. Zu diesem Zeitpunkt war ich allerdings schon gut mit der Delphi IDE vertraut, und auch weitestgehend mit der Sprache Pascal. Erst ab dann hat sich alles hauptsächlich um die Konzepte gedreht.
Ich will nicht sagen, dass es falsch wäre diese "Meta"-Disziplinen anfangs ausser Acht zu lassen - bei vielem genügt es aber gerade am Anfang, sie einfach nur schon ein mal gehört zu haben. Die Menge an Programmen, die ich gebaut habe, ohne - nach heutiger Sicht - zu wissen, was ich tat, ist erschreckend . Aber es waren eben diese, die dazu führten, dass ich beim "ernst werden" nicht mehr viel über Kleinigkeiten der Sprache oder die Menüstruktur von Delphi nachdenken musste.

Was ich sagen will: Es ist einfach unerlässlich sich kleine Ziele zu suchen, die man minuziös versucht umzusetzen. Das kann in Einzelfällen auch Wochen dauern, aber eben dieser Biss zahlt sich nachher dadurch aus, dass man mit den ganz zugrunde liegenden Dingen nachher per Du ist, und sich um Konzepte und Strategien kümmern kann, ohne sich in Semantik zu verlieren. Keine Frage, das werden Programme sein, die man nach ein paar Jahren lieber peinlich berührt verschweigen will, aber die sind so wichtig! Der erste Taschenrechner, das erste "Spiel" aus 10000 TImage-Komponenten, der erste Sound den man mit 20 Jahre alten und lang abgekündigten API Funktionen abspielt, die ersten kaputt geschriebenen Dateien, weil Streams gegenüber "file of ..." so unnötig kompliziert erscheinen, der erste Thread, mit dem man fröhlich auf die GUI zugreift und Bekanntschaft mit den unerklärlichsten Zugriffsverletzungen macht... alles Dinge, für die man in Foren so gerne gerüffelt wird, die aber doch einfach Erfahrungen sind, die wie ich finde fest zum Lernprozess gehören. Einfach mal sich trauen ein Programm zu bauen. Irgendwas.

Bei meinen ersten QBASIC Gehversuchen war ich überglücklich, dass 10 Zeilen "**********" im DOS erschienen. Viel später kam ein "DOS-Emulator", der einfach nur so tat, als würde gerade das BIOS das RAM durchtesten (ja, ich war davon überzeugt, dass JEDER PC 4096kB davon hatte ), und nachher nach Kommandozeile aussah, intern aber auch nur alles ans DOS weiterreichte. Dann irgendwann der 256-Farben Mode - WOOHOO! (Co)Sinus-Funktion gefunden -> Lissajous Firugen! (Ich wusste bis nach meinem Studium nicht, dass sie so hießen. Sie waren einfach hübsch und farbig.) Als Krönung irgendwann ein über Monate gebauter, grafisch völlig übler, Space Invaders Klon, der so grottig programmiert war wie nur möglich. Aber es war ein spielbares Spiel! (Zumindest auf einem 386DX40, alles drüber wurde unspielbar schnell.) Aus heutiger Sicht alles diletantisch und völlig naiv gemacht, aber es waren kleine Ziele mit Erfolgen, die letztlich dazu geführt haben, dass das Handwerk an und für sich zu eben diesem werden konnte: Einem "Handwerk". Wirklich "entwickeln" kam erst etliche Jahre später.

Gerade Delphi macht einem die kleinschrittigen Erfolge relativ einfach. Nutze sie! Schreibe kleine unwichtige Programme voller Fehler, und völlig an jedem Ideal vorbei! Zerpflücke Google bei Problemen, sie werden halbstündlich dabei auftreten. Lasse dir in Foren hunderte Zeilen überheblich klingender "guter Ratschläge" entgegenschmettern - die Kunst ist es, die paar guten nüchternen Infos daraus zu extrahieren, den Rest doof zu finden, und dennoch ans Ziel zu kommen. So wie du klingst, wirst du aber auf weit mehr freundliche und hilfsbereite Leute treffen als die "ich will mal eben"- und "ich brauch für Schule und zwar morgen früh"-Faulpelze, die man hier und auch woanders so prominent wahrnimmt (weil sie einem zuweilen echt das Blut zum kochen bringen vermögen).

Probrammieren ist einfach wie so vieles. Man muss voll Krarracho gegen die Mauern rennen um zu erkennen, dass es sie gibt. Dann kann man sich nach und nach an deren Überwindung begeben, egal ob alleine mit Dokus und Suchen, oder durch Fragen bei anderen. Aber man muss los laufen, nur Theorie bis zum Master-Grade kann keiner so wirklich. Und selbst wenn: Es ginge viel zu viel Praxiserfahrung und erlernter Pragmatismus dabei auf der Strecke.

Zur Ausgangsfrage "Delphi lernen, wie vorgehen": Button auf das Formular, Doppelklick drauf, zwischen "begin" und "end" ein ShowMessage(Was'n hier los'n!?); schreiben, F9 drücken, Fehlermeldung kassieren, googlen, fragen, Doku lesen: Bumms -> Du wirst ab jetzt wissen, was Strings und Datentypen generell sind, wie und warum sie sich unterscheiden, und dass ShowMessage() eine Funktion ist, die einen Parameter eines bestimmten Typs braucht. Die Vorgehensweise lässt sich praktisch beliebig durchziehen, sie nennt sich "einfach mal machen"

[Bbommel]

Medium und andere haben mit ihren Antworten ja jetzt eigentlich fast alles gesagt, was es zu sagen gibt.

Eins möchte ich aber noch mal unterstreichen: bis heute hilft es mir beim Erlernen neuer Sprachen und auch von für mich neuen Konzepten innerhalb der Sprache immer, diese an einer konkreten Aufgabe auszuprobieren. Und das ist vielleicht erst mal das schwierigste: überlege dir irgendein kleines Tool, dass du schreiben willst. Das darf gerne auch etwas sein, das es schon längst gibt - der tausendste Taschenrechner, der millionste Vokabeltrainer - vielleicht gibt es aber ja auch wirklich etwas, was du brauchen kannst und das es noch nicht gibt. Nur nicht zu komplex anfangen.

An diesem Tool kannst du dich dann austoben und du hast ein Ziel, wo du hin möchtest und dann kannst du auch gezielt bestimmte Dinge im Buch noch einmal nachlesen und ausprobieren. Wichtig ist es dann, dass du bei dem, was du entwickeln willst, dir erst mal auch kleine Teilaufgaben überlegst.

Beispiel Taschenrechner: Bevor das Ding rechnet, bastelst du in einem Fenster vielleicht erst mal etwas zusammen, das wir ein Taschenrechner aussieht, also die ganzen Knöpfe und eine Anzeige. Dann würdest du vielleicht dafür sorgen wollen, dass, wenn man auf die "1" klickt, diese dann auch in der Anzeige erscheint. Und so weiter, bis es dann immer komplexer wird.

Viel Spaß auf jeden Fall beim Einstieg ins Programmieren!

[DeddyH]

Zitat von Medium:

..., und dass ShowMessage() eine Funktion ist, die einen Parameter eines bestimmten Typs braucht.

ShowMessage() ist eine Prozedur