GDI+ und C# - Lohnt sich ein Buch dafür?
-
Ich habe mir nun ein Buch über C# gekauft. "Viusal C# - Grundlagen, Programmiertechniken, Windows-Programmierung" von Frank Eller und Michael Kofler. Das Buch kann ich allerdings nur weiterempfehlen.
So jetzt bin ich im GDI+ Abschnitt, und dort wird gesagt, dass diese Grafikschnittstelle derzeit noch langsamer als GDI ist, da noch keine Hardware Unterstützung dafür vorhanden ist. Dies würde sich aber ab Windows Longhorn ändern.
Nun hier meine Frage, selbst wenn sich das mit Windows Longhorn ändert, kann ich mich doch nicht darauf verlassen, dass alle User meine Programms auf Windows Longhorn umsteigen? Lohnt sich daher überhaupt ein Buch dafür. Wofür würde sich ein Buch lohnen. Welche Anwendungen zum Beispiel? Wenn ich nur für einfache Dinge benötige, würde es reichen im Internet zu lesen?
Gruß
Markus Seidl
-
Am ehesten würde ich zu nem Buch über XML greifen, da XML auch bei Longhorn eine Rolle spielen wird, wenn ich richtig informiert bin (soll iirc sogar möglich sein per XML Datei die GUI zu erstellen).
-
Das heißt du rätst davon ab. Dachte ich mir schon. Ich würd auch bei mir sagen, dass ich nicht mehr als das Basiswissen brauche. Für richtiges 2D sollte man dann wohl doch eher auf das das DirectDraw zurückgreifen, oder?
Von XML habe ich schon viel gehört, und noch nie verstanden WAS es eigentlich ist. Viele sagen ja, das XML nicht mehr als PlainText ist. Nur durch die Interpretation wird es zu etwas fähig. Gut, bei einer Executable haben wir den Fall auch, nur das die Zeichen Byteweise etwas verkommen sind ;). Wenn ich von XML Spreche, und wie du es sagst, per XML Datei eine GUI zu erstellen, wie stelle ich mir das vor? Nur Text, oder isses Text der einen eigenen Compiler noch braucht?
Ist XML wirklich nur mehr oder weniger ein Protokoll, WIE Text gefüllt wird, damit er entsprechend ausgelesen werden kann? Oder was muss ich mir darunter vorstellen?
Und wenn wir gleich dabei sind, kennt dann jemand gleich ein Buch DAFÜR?
-
XML (Extensible Markup Language) bezeichnet einen Standard zur Definition von Auszeichnungssprachen. Es hat Ähnlichkeit mit HTML.
<?xml version="1.0"?> <enzyklopaedie> <eintrag> <stichwort>Genf </stichwort> <eintragstext>Genf ist der Sitz von...</eintragstext> </eintrag> </enzyklopaedie>
(Kurze und gute Infos über XML unter http://www.w3c.de/Misc/XML-in-10-points.html.)
Aber nun zum Zusammengang mit der Longhorn-GUI:
Der neue Aufbau von Windows unter Longhorn sieht unter anderem eine strikte Trennung von funktionellen Programmteilen einer Applikation und seiner GUI vor. Um diese GUIs dann möglichst portabel zu halten (auch im Zuge der "Software as a Service"-Kampagne (die Idee, Software als Webanwendung anzubieten)), hat man also eine Markuplanguage zur Beschreibung der GUI gewählt.
So ähnlich wie mit HTML-Tags baust du dann also deine grafische Oberfläche auf und verknüpfst die einzelnen Elemente (z.B. <button ...> mit den funktionalen Elementen deiner Applikation.Genial, oder?
Jedenfalls geschieht u.A. diese Sache mit XML und noch tausend andere... Microsoft fährt voll auf den Kram ab.
-
Also doch nicht mehr als PlainText, der seine Funktion erst durch den richtigen Interpreter bekommt.
Aber nachdem es 1000 andere Interpreter dafür gibt (ich muss XML ja schließlich nicht NUR für GUI's benutzen) macht es doch nicht wirklich Sinn sich dafür ein Buch zu holen. Oder gibts doch etwas, was jeder Interpreter bieten MUSS?
-
Du kannst natürlich jede Menge fertige Parser usw. verwenden und musst dich nicht selbst damit rumärgern, aber XML bietet dir sehr vieles, so kannst du eigene Regeln zum parsen und Vorschriften für einzelne Elemente bzw. Attribute für die Tags festlegen. Und dann gibts noch StyleSheets für die Formatierung der XML Dateien (nennt sich XSLT).
Ihr Traum ist es wohl, dass jede Anwendung nur noch XML ausgibt und somit von jedem Medium ausgegeben werden kann, z.B. über ne Webseite, in ner anderen Anwendung, über nen GUI Interface dazu,...
So könnte z.B. die Kernanwendung von einem Programmierer entwickelt werden und dieser liefert alle Ausgaben in XML verpackt, ein Grafiker/Webdesigner kann diese mit Stylesheets und XHTML aufbereiten und schön grafisch verpackt darstellen, oder ein anderer Programmierer bastelt die GUI (wäre ja auch mit XML möglich) und zeigt dort deine in XML verpackten Daten an, usw.
Ihr Hauptgrund ist wohl der, dass man in Zukunft viele Webdienste hat und du im Grunde nur noch die GUI kaufst und das Kernsystem sicher bei ihnen zuHause steht.
-
Oder gibts doch etwas, was jeder Interpreter bieten MUSS?
Würd ich auch gerne wissen
Zu XML wurde schon das Wichtigste gesagt. Simpel ausgedrückt ist es ne Metasprache zur Definition von Metasprachen
Im Umfeld von XML gibt es jedoch unglaublich viele Techniken drum herum (alleine mit XML-Schema oder XSLT kann man sich Ewigkeiten beschäftigen).
Der Vorteil von XML ist, dass die Daten so interpretiert und transformiert werden können, wie man es gerade braucht.Noch ne kurze allgemeine Frage: Für ein Zeichenprogramm (Paint) reicht die Geschwindigkeit von GDI+ doch allemal, oder?
-
Zu GDI +:Im wesentlichen schon. Das Problem ist nur, dass man nicht mal nen simplen Pixel auf eine Graphics Fläche Zeichnen kann, kann man aber wieder umgehen, in dem man eine Fläche mit Kantenlänge 1 zeichnet (langsamer gehts aber wohl nicht mehr, aber selbst das wäre noch schnell genug, um mit einem Stift auf die Fläche zu zeichnen). D.h. müsste in die Datei direkt bearbeiten (ist schon wesentlich schneller). Und ich weiß dann nicht wie man das in Echtzeit anzeigen lassen kann.
Aber an sich bietet die GDI+ alles was du dafür bräuchtest. Aber dafür würde sich dann wirklich ein Buch lohnen, nur will ICH kein Paint machen.
Zu XML: Ich habs schon verstanden. PlainText mit entsprechenden Parser. Aber dafür muss ich doch wirklich kein Buch holen. Sowas mach ich doch jetzt schon in der Registry oder in einer Textdatei. Am ehesten würde sich, bevor ich XML für meine Programme nehme, das Serialisieren anbieten. Das was ich an XML brauchen würde, das kann ich mir durch die unterschiedlichen Sites auch beibringen. Die Regelwerk gibts irgendwo im Netz. Beispiele werde ich dafür auch finden. Parser muss man sich ja eh selber schreiben. Ich werds mir aber trotzdem mal bei Gelegenheit reinziehen.
Damit bedanke ich mich für die vielen Antworten, und für die Erkenntniss dass ich mir jetzt gar kein Buch kaufen werde
is ja beides für mich sinnlos. Und man lernt doch nichts, wenn man es nicht braucht. Ich kann mir hier doch kein Buch zulegen, es durchlesen, und das Wissen niemals benutzen.
Gruß
Markus Seidl
-
Angren Aldaron schrieb:
Parser muss man sich ja eh selber schreiben.
Gott sei Dank nicht
-
Das meine ich jetzt im kleinen Rahmen. Einen Parser für HTML Dokumente würde ich auch nur ungern schreiben wollen. Aber wenn ich jetzt eine Textdatei auslese und dass nach einem bestimmten Format mache, um Variablen zu initialisieren, könnte man diese Routine doch auch schon als Parser bezeichnen. Ich könnte die Textdatei ja dann schließlich "programmieren". Zwar ein bischen weit hergeholt, im Grundprinzip machen es die HTML Parser jedoch nicht anders.
Aber ich weiß, XML gibt eine bestimmte Schreibweise vor, womit es dann möglich ist, die Datei einfach auszulesen. Wie ich schon gehört habe, soll es, zumindest im Ansatz, ein XML Parser in C# geben. Wie man den benutzt weiß ich zwar noch nicht, aber das werde ich bestimmt auch bald raushaben.
Gruß
Markus Seidl
-
Angren Aldaron schrieb:
Das meine ich jetzt im kleinen Rahmen. Einen Parser für HTML Dokumente würde ich auch nur ungern schreiben wollen. Aber wenn ich jetzt eine Textdatei auslese und dass nach einem bestimmten Format mache, um Variablen zu initialisieren, könnte man diese Routine doch auch schon als Parser bezeichnen. Ich könnte die Textdatei ja dann schließlich "programmieren". Zwar ein bischen weit hergeholt, im Grundprinzip machen es die HTML Parser jedoch nicht anders.
Aber ich weiß, XML gibt eine bestimmte Schreibweise vor, womit es dann möglich ist, die Datei einfach auszulesen. Wie ich schon gehört habe, soll es, zumindest im Ansatz, ein XML Parser in C# geben. Wie man den benutzt weiß ich zwar noch nicht, aber das werde ich bestimmt auch bald raushaben.
Gruß
Markus Seidl
.NET bringt ALLES mit, was du zum parsen von XML brauchst (egal, wie du vorgehen willst, ob DOM, SAX per Stream etc)
http://www.csharpfriends.com/quickstart/aspplus/samples/classbrowser/cs/classbrowser.aspx?namespace=System.Xml
-
HAuauauaua, OK Ok ok, habs schon kapiert.
Wusste zwar DASS .NET etwas mitliefert, aber nicht wieviel. Sind ja mal viele Klassen, nur um ein bischen Text auslesen zu können. SEEHR interessant, wie Microsoft da vorgeht ;).
Jut Danke. Vielleicht muss ich mir dafür doch noch ein Buch holen, wenn ich mal nen XML Browser schreiben möchte
Gruß
Markus Seidl
-
Alleine schon die Tatsache,dass der Parser die Regeln aus ner DTD parst und erstellt, bevor er das eigentliche XML Dokument anrührt ist schon sehr aufwändig und sei froh, dass dir MS die Arbeit abnimmt
-
Tja wenn die das nicht machen würden, würde ich mich mit XML garnicht beschäftigen wollen, ich programmiere ja kein Betriebssystem, bei dem es auf einheitliche Konventionen ankommt. Wenn ich Werte speichern möchte, kann ich das über die Registry machen (bin ich noch nie so begeisterter Fan davon gewesen) oder ich serialisier eine Klasse dafür. ODER ich bediene mit dem alten INI Prinzip. Zahl1 = 5 usw, damit kann ich eine Textdatei einmal einlesen. Nach der Stelle "Zahl1" suchen, und den Wert dahinter wieder als Zahl auflösen.
NUR weil mir die Arbeit schon abgenommen wurde, beschäftige ich mich mal damit. Jetzt bin ich aber erstmal damit beschäftigt diese OpenSource FTP Klasse ein bischen zu überarbeiten. Und da brauche ich beileibe kein XML. Hab schon genug damit zu tun, dass die Klasse bei meinen Arbeiten sich nicht in ihrer Funktionalität ändert.
Gruß
Markus Seidl