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 :-D - 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 :zwinker:


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 8-)

[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? :D 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 :stupid:), 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

Delphi-Quellcode:

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:

Zitat von Medium (Beitrag 1215160)

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

ShowMessage() ist eine Prozedur :lol:

[Furtbichler]

Nun ja. Eine 'procedure' schon und keine 'function', aber sie ist/hat eine Funktion. :stupid:

[Medium]

Grummel. Guckt auf die Uhrzeit meines Beitrages, da ist so ein Pätzerchen erlaubt :drunken:

[baumina]

Schöner Beitrag Medium, man findet sich darin selbst wieder!

Also ich habe Datenverarbeitungskauffrau gelernt (den Beruf gibt's so schon nimmer). Mein Lehrer für Cobol-Programmierung hat sich sein Wissen jeweils mittels Buch kurz vor der Stunde angeeignet. Man konnte ihn also niemals fragen was erst 3 Seiten später stand, also der Unterricht war komplett untauglich.

Bei meinem Chef habe ich "Smart" gelernt. Das war sowas wie Office und VBA, die Programmiersprache war auf deutsch! Durch anfängliches Zusehen habe ich sehr viel gelernt. Auch heute schaue ich Programmierern gerne über die Schulter, denn jeder hat einen anderen Stil und eine andere Denkweise an ein Problem ran zu gehen.

Ja, man muss sich einfach irgendwann einmal trauen irgendwas zu programmieren, auch wenn es anderen dabei die Haare zu Berge stehen lässt. Von heute auf morgen kann man nicht alles wissen, nein, man kann NIE alles wissen, man kann sich nur immer weiter entwickeln.

Auf jeden Fall wünsche ich dir viel Spaß dabei, denn ich programmiere seit über 25 Jahren richtig gerne, auch wenn ich in der Zeit das Rad mindestens schon 100 mal neu erfunden habe, es sieht doch jedesmal ein wenig anders und schöner aus.

[Codehunter]

Wenn ich so zurückdenke wie bei mir das alles mal angefangen hat... 1991, mein erster eigener Computer - natürlich ein Amiga 500. Aufgebaut war er in 20 Minuten und eigentlich idiotensicher. Betriebssystem-Diskette rein und fasziniert zugeschaut, wie sich die Sache so auf dem Fernseher aufbaut. Im Handbuch stand etwas von einer Extras-Diskette, die kam dann auch gleich rein. Und ratet mal, was dort als Icon erschien. Amiga BASIC. Kein Witz: Das allererste Programm das ich auf meinem allerersten Computer per Maus gestartet habe war eine Entwicklungsumgebung. Und die war auch noch von Microsoft. Geschadet hats trotzdem nicht :-D

Ganz ehrlich, das Handbuch zu Amiga BASIC war eines der besten das mir jemals unter kam. Für jedes einzelne Keyword und jede Funktion dieser Sprache gab es mindestens eine volle Buchseite Beschreibung. Die praktischen Beispiele waren stark grafikorientiert und so lernte ich gleich mal den Umgang mit Pixeln und Koordinaten. Diese Erfahrungen, nun schon 22 Jahre alt, helfen mir heute noch bei der Entwicklung grafischer Komponenten.

Mein Masterplan damals auf Amiga BASIC war es, einen Nadeldrucker anzusteuern. Die Standard-Epson-ESC-Sequenzen standen ja auch im Amiga-Handbuch. Ich hab damals nicht eher locker gelassen bis ich den Drucker zum Drucken von Grafik nutzen konnte - mangels Druckertreibern die im OS integriert sind damals ein Horror. Dann schrieb ich ein kleines Malprogramm, sehr primitiv gehalten. Mit der Maus einen Cursor bewegen und bei gedrückter Maustaste eine weiße Linie zeichnen. Meine gestalterischen Fähigkeiten waren damals schon sehr bescheiden und sind heute auch nicht viel besser ^^ Jedenfalls sollte diese handgemalte Grafik zu Papier gebracht werden und das gelang mir irgendwann auch (glaub nach 3 Jahren oder so).

Am Anfang ist es ganz normal, dass man praktisch nach jeder neuen Zeile Code die man schreibt, das Programm einmal laufen lässt um zu sehen was passiert. Das ist zwar nicht sehr effektiv, hilft aber ungemein beim Lernen. Mit der Zeit werden die Codeabschnitte immer länger die man am Stück schreiben kann. Man weiß einfach irgendwann wie alles zusammenhängt. Heute schreibe ich gelegentlich 1000 Zeilen am Stück bevor ich überhaupt was habe das ich testen kann. Wenn dann beim ersten Compilerdurchlauf keine Errors auftreten, weil ich irgendwo ein schließendes END vergessen oder statt einem ";" ein ":" getippt habe, dann sind das so die kleinen Glücksmomente - kommen aber höchst selten vor. Was aber nicht heißt dass der Code beim ersten Versuch auch gleich das tut was er soll.

Tatsache ist, mit einem halbwegs aktuellen Delphi, das ohne Adminrechte unter Win 7 läuft (tut IMHO schon D7) kann man eigentlich nichts kaputt machen. Darum kann man als Anfänger einfach drauflos coden, Fehler machen, daraus lernen und am Ende was nettes erschaffen. Als Anfänger sollte man froh sein, dass man nicht unter Erfolgsdruck steht und sich mit Nonsens befassen kann. Dann macht Programmieren noch richtig Spaß. Wenn man später Programme schreibt für Businessanwendungen, kann die Arbeit sehr nüchtern und trocken sein. Darum werf ich auch heute noch manchmal kleine Opensource-Projekte in die Welt, einfach um zu sehen was andere davon halten und vorallem um mal was vollkommen anderes zu machen als im Alltag. Schade nur, dass so selten Zeit dafür ist.

[BMI]

hatte neulich mal das Problem unter Win 7, daß bei Delphi 7 PE der Debugger (Anzeige der Variableninhalte bei MouseOver über den Variablen beim Durchsteppen/Haltepunkt keine Hints anzeigte.) Probleme machte.
Hatte das schonmal jemand?

[Paul13]

Wow.

Vielen Dank für die ganzen ausführlichen Antworten!
Jetzt bin ich noch mehr motiviert :).


Grüße Paul

[stahli]

Hast Du auch Delphi 7 oder nur das Buch?
Die Frage ist wichtig im Zusammenhang mit Datenbanken.
Wenn Du Delphi 7 hast, dann kannst Du die "BDE" (Borland Database Engine) verwenden und so (etwas später :-)) relativ einfach den Umgang mit Datenbanken lernen.
Die neueren Delphi-Versionen haben zwar z.T. professionellere und stabilere Datenbanken, der Umgang damit ist aber komplizierter und insgesamt wird das deutlich teurer in der Anschaffung.

[Paul13]

Hi,

ja ich habe Delphi 7 Enterprise

Grüße
Paul

[nahpets]

Hallo,

bei Delphi gibt es doch das Verzeichnis Demos, schau doch einfach mal unverbindlich da durch und gucke, ob sich die Programme kompilieren lassen, lies im Buch nach, was da so im Quelltext alles steht, benutze intensiv die Hilfe von Delphi, auch dort gibt es, neben Erklärungen, vielfältige Beispiele (also z. B. Cursor auf das, was Du nicht verstehst und F1 drücken), mache kleine Änderungen. Funktionen hinzufügen, die Du für sinnvoll erachtest. Bei Problemen die auftreten: Buch nehmen, suchen wo das Passende beschrieben wird, lernen umsetzen. Klappt es nicht, hier nachfragen. Möglichst konkrete Fragestellung mit Quellcode, was Du gemacht hast, was Du nicht verstehst...

Im Dialog zwischen Delphi, Deinem Buch und dem Forum wirst Du sicherlich recht schnell zum Grundwissen für eigene, einfache Programme kommen. Und dann immer wieder probieren, studieren, probieren, studieren...

Die für mich bisher beste Methode, um etwas zu erlernen, war "Learning by doing". Also Lernen und machen. Das abstrakte Lernen des Programmierens, also nur erstmal der Theorie, ist doch eher schwierig. Habe das zwar so gemacht, weil es damals noch keine PCs gab, aber verstanden habe ich vieles eigentlich erst, nachdem ich es in die Praxis umsetzen durft, sprich die Möglichkeit hatte, das erlernte am Rechner umzusetzen.

Übrigens: ein guter Programmierer hat einen gesunden Spieltrieb und spielerisch lernen kann sehr effektiv sein. Alle kleinen Kinder (nicht nur die der Menschen) lernen so. Und große Kinder (auch die über 50 ;-)) dürfen so lernen.
Will meinen: Probiere ruhig aus, "was passiert, wenn ich dies oder das mache..."

Bin so im Laufe meiner "Programmiererlaufbahn" auf mancheine verblüffende und gute Lösung gestoßen.

[stahli]

Wenn Du mal Zeit und Lust zum schmökern ;-) hast:
http://www.delphipraxis.net/157246-d...ihr-damit.html
http://www.delphipraxis.net/158403-v...t-zukunft.html

PS: Die DelphiPraxis kann die Threads auch für den Druckmodus stylen...

[cookie22]

Zitat:

Zitat von stahli (Beitrag 1215224)

Wenn Du Delphi 7 hast, dann kannst Du die "BDE" (Borland Database Engine) verwenden und so (etwas später :-)) relativ einfach den Umgang mit Datenbanken lernen.

Die BDE ist toter als tot. Fang erst ganicht mit so etwas an. Lern, wenn du Datenbanken lernen willst, etwas aktuelles. Mit der BDE tust du dir keinen gefallen.