{"id":55000002,"date":"2015-02-01T00:00:00","date_gmt":"2020-12-23T11:02:58","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=2"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Von_VBA_zu_C_Erste_Anwendung_und_Variablen","status":"publish","type":"post","link":"https:\/\/vbentwickler.de\/Von_VBA_zu_C_Erste_Anwendung_und_Variablen\/","title":{"rendered":"Von VBA zu C#: Erste Anwendung und Variablen"},"content":{"rendered":"

Wer von VBA zu C# wechselt, muss an einigen Stellen umdenken. Der Sprung von VBA zu Visual Basic unter .NET wäre möglicherweise etwas einfacher, allerdings ist C# wohl die weiter verbreitete Sprache. Das bedeutet nicht nur, dass es mehr Entwickler gibt, die damit entwickelte Anwendungen leichter weiterentwickeln oder Sie unterstützen können, sondern es existieren auch mehr Beispiele zu C# im Internet als zu Visual Basic. Im ersten Artikel der Kategorie “Von VBA zu C#” schauen wir uns an, wie Sie eine erste kleine Konsolenanwendung bauen und welche einfachen Datentypen es dort gibt.<\/b><\/p>\n

Für die Beispiele dieser Artikelreihe wollen wir jeweils eine Konsolenanwendung verwenden. Damit können wir uns auf die Sprache selbst konzentrieren und müssen uns nicht mit zusätzlichen Elementen wie etwa der Benutzeroberfläche beschäftigen. Eine Konsolenanwendung erstellen Sie über den Menübefehl Datei|Neu|Projekt<\/b>. Dies zeigt den Dialog Neues Projekt <\/b>an, wo Sie das Zielverzeichnis und den Namen des Projekts angeben sowie die Projektvorlage auswählen – in diesem Fall Vorlagen|Visual C#|Windows-Desktop|Konsolenanwendung<\/b>.<\/p>\n

Ein Klick auf die Schaltfläche OK <\/b>legt dann ein neues Projekt an, das im Wesentlichen aus einem Klassenmodul namens Program.cs <\/b>besteht. Klassenmodule sind Ihnen, wenn Sie bereits mit VBA programmiert haben, ein Begriff – dort gab es die zu Formularen oder Berichten gehörenden Klassenmodule oder alleinstehende Klassenmodule, die Sie ähnlich wie Standardmodule angelegt haben.<\/p>\n

Unter VBA war der wesentliche Unterschied zwischen Klassenmodulen und Standardmodulen, dass Sie zunächst ein Objekt auf Basis des Klassenmoduls erstellen mussten, um auf die enthaltenen Elemente wie etwa Methoden oder Eigenschaften zuzugreifen, während Sie die in Standardmodulen enthaltenen Prozeduren oder Funktionen direkt etwa über den Direktbereich des VBA-Editors aufrufen konnten.<\/p>\n

Von der Idee der Standardmodule können Sie sich nun verabschieden, denn unter C# gibt es nur noch Klassenmodule. In unserem neuen Projekt heißt das aktuell einzige Exemplar Program.cs<\/b> und sieht wie in Bild 1 aus. Was es mit den using<\/b>-Anweisungen und den Elementen namespace<\/b>, class <\/b>und static void <\/b>auf sich hat, schauen wir uns weiter unten an.<\/p>\n

\"Standardmäßig<\/p>\n

Bild 1: Standardmäßig vorhandenes Klassenmodul in einem neuen C#-Projekt<\/span><\/b><\/p>\n

Erster Test<\/b><\/p>\n

Die Konsolenanwendung heißt so, weil die Ausgabe in der Konsole erfolgt, also in einem Fenster wie der Eingabeaufforderung. Um dort einen Text auszugeben und das Fenster durch Betätigen der Eingabetaste wieder zu schließen, ergänzen Sie die Prozedur, die mit der Zeile static void Main… <\/b>beginnt, durch zwei Zeilen, die Sie wie folgt zwischen den geschweiften Klammern einfügen:<\/p>\n

static void Main(string[] args)\r\n{\r\n     Console.WriteLine(\"Eingabetaste drücken!\");\r\n     Console.ReadLine();\r\n}<\/pre>\n
Ein Klick auf die Taste F5 <\/b>oder die Auswahl des Menüeintrags Debuggen|Debugging starten <\/b>sorgt für die Anzeige des Fensters aus Bild 2, das Sie durch Betätigen der Eingabetaste wieder schließen.<\/p>\n
\"Anzeige<\/p>\n
Bild 2: Anzeige der Konsole mit dem gewünschten Text<\/span><\/b><\/p>\n
Der erste Befehl, die Methode WriteLine <\/b>des Objekts Console<\/b>, hat also zunächst für die Anzeige des Textes in der Konsole gesorgt. Damit die Konsole danach nicht direkt wieder verschwindet, haben wir die ReadLine<\/b>-Methode des Console<\/b>-Objekts hinterhergeschickt. Diese unterbricht den Ablauf des Programms, bis der Benutzer die Eingabetaste betätigt.<\/p>\n
Alternativ zu ReadLine <\/b>hätten wir auch die Methode ReadKey <\/b>nutzen können, die auf die Betätigung einer jeden Taste reagiert:<\/p>\n
Console.ReadKey();<\/pre>\n
Semikolon als Zeilenabschluss<\/b><\/p>\n
Sie haben es schon erkannt: Unter C# müssen Sie jede Anweisung mit einem Semikolon beenden. Es reicht nicht aus, wie unter VBA einfach die neue Anweisung in die nächste Zeile zu schreiben. Hier ist das Semikolon das Maß aller Dinge bei der Kennzeichnung des Endes einer Anweisung. Dafür können Sie unter C# auch mehrere Anweisungen in eine Zeile schreiben – Sie müssen diese nur durch das Semikolon voneinander trennen.<\/p>\n
Dies sähe dann für unser Beispiel so aus:<\/p>\n
Console.WriteLine(\"Eingabe...!\");Console.ReadLine();<\/pre>\n
Zeilen umbrechen<\/b><\/p>\n
Durch den zwingenden Zeilenabschluss per Semikolon können Sie Zeile im Gegensatz zu VBA etwas komfortabler aufteilen – zum Beispiel so:<\/p>\n
Console.WriteLine(\r\n     \"Eingabetaste drücken!\");<\/pre>\n
Sie müssen also nicht etwa das Unterstrich-Zeichen angeben, um den Zeilenumbruch zu markieren. Leider gelingt das nicht mitten in einem Literal, also innerhalb von Anführungszeichen. Folgendes führt zu einem Kompilierfehler, der übrigens rot unterstrichen markiert wird:<\/p>\n
Console.WriteLine(\"Eingabetaste \r\n     drücken!\");<\/pre>\n
Außerdem können Sie sich bei dieser Gelegenheit gleich mit der Fehlerliste von Visual Studio bekanntmachen, die Sie sicher noch häufiger konsultieren werden – und zwar mit dem Menüeintrag Ansicht|Fehlerliste <\/b>oder der Tastenkombination Strg + ^, E<\/b> (also erst Strg + ^<\/b>, dann E<\/b>).<\/p>\n
Ungewohnte Klammern<\/b><\/p>\n
Nicht nur, dass Sie sich mit geschweiften Klammern herumschlagen müssen, die einen Codeblock beispielsweise innerhalb eines Namespaces, einer Methode oder auch eines Konstrukts wie einer Schleife oder einer Bedingung markieren – C# verlangt auch nach allen möglichen Methoden nach der Angabe eines Klammernpaares. Dies geschieht unabhängig davon, ob Parameter zu übergeben sind oder nicht. Sollten Ihnen also einmal ein Syntaxfehler über den Weg laufen, den Sie sich auf den ersten Blick nicht erklären können, prüfen Sie, ob die Anweisung eventuell nach einem Paar abschließender Klammern verlangt.<\/p>\n
Fehlerliste<\/b><\/p>\n
Diese sieht in diesem Fall wie in Bild 3 aus. Mehr Syntaxfehler kann man wohl kaum per Einzeiler provozieren. Sie können diese Anzeige jedoch zum Anlass für die erste Erkundung der Fehlerliste nutzen, die es im VBA-Editor ja gar nicht gibt: Diese zeigt genau, wo der Fehler vorliegt und um was für einen Fehler es sich handelt. Im Gegensatz zum VBA-Editor, wo etwa beim Debuggen nur ein Syntaxfehler nach dem anderen moniert wird, finden Sie hier gleich eine Liste aller aktuell vorliegenden Syntaxfehler.<\/p>\n
\"Fehlermeldungen\"<\/p>\n
Bild 3: Fehlermeldungen<\/span><\/b><\/p>\n
Noch schöner ist, dass Sie per Doppelklick auf einen der Einträge direkt zu der fraglichen Stelle im Code springen können. Darüber hinaus zeigt die Fehlerliste auch die Datei (also in diesem Fall die Klasse), die Zeile und die Spalte des Fehlers an. Sie könnten sich also auch über die Zeilennummer den Fehler anschauen – vorausgesetzt, dass das Codefenster gerade die Zeilennummern anzeigt. Im Screenshot ist dies nicht der Fall, aber Sie blenden die Zeilennummern ganz einfach mit der Option Zeilennummern <\/b>in den Visual Studio-Optionen (Extras|Optionen<\/b>) im Bereich Text-Editor|Alle Sprachen <\/b>ein (siehe Bild 4).<\/p>\n
\"Einblenden<\/p>\n
Bild 4: Einblenden der Zeilennummern<\/span><\/b><\/p>\n
Im vorliegenden Fall beheben Sie die knapp zehn Fehler übrigens, indem Sie den Zeilenumbruch innerhalb der Zeichenkette wieder entfernen.<\/p>\n
Groß und klein<\/b><\/p>\n
Wenn Sie schnell einen Syntaxfehler provozieren möchten, brauchen Sie nur einmal WriteLine<\/b> mit ausschließlich kleinen Buchstaben zu schreiben. Visual Studio korrigiert dies nicht – zumindest dann nicht, wenn Sie die IntelliSense-Option nicht nutzen.<\/p>\n
Stattdessen zeigt die Fehlerliste den Fehler “System.Console” enthält keine Definition für “writeline”. <\/b>an.<\/p>\n
Die Groß- und Kleinschreibung ist also wichtig – Visual Studio erkennt Elemente der Objektbibliothek nicht, wenn diese nicht hundertprozentig richtig geschrieben sind.<\/p>\n
Dies gilt übrigens auch für die Benennung von Objekten, Variablen et cetera: Sie können durchaus zwei Variablen namens kundeid <\/b>und KundeID <\/b>verwenden. Durch die unterschiedliche Groß- und Kleinschreibung werden diese als verschiedene Variablen erkannt.<\/p>\n
Blockweise<\/b><\/p>\n
C#-Code ist, bis auf die oberste Ebene, immer in Blöcke eingefasst. Ein Block wird durch eine öffnende geschweifte Klammer vor dem Block und eine schließende geschweifte Klammer hinter dem Block gekennzeichnet.  Blöcke stehen meist in einem bestimmten Kontext, beispielsweise als Inhalt einer Methode, eines Namespaces, einer Schleife oder einer Bedingung.<\/p>\n
Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!<\/span>
\nHier geht es zur Bestellung des Jahresabonnements des Magazins Visual Basic Entwickler<\/strong>:<\/span>
\nZur Bestellung ...<\/a><\/span>
\nDanach greifen Sie sofort auf alle rund 200 Artikel<\/strong> unseres Angebots zu - auch auf diesen hier!<\/span>
\nOder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:<\/span><\/p>\n<\/div>\n\n\t\n\t
\n\n\t\t\n\t\t