Win-API Kapselungen - welche Lernen?
-
Wenn ich ein vernünftiges Buch habe, das z.B. die MFC beschreibt, dann steht da auch drin, wie das Fenster upgedated wird - und zwar ohne das man die WinAPI benötigt! Und die paar Defines für die Updates... na, da muß man nun wirklich nicht die WinAPI wälzen. Das steht auch in jedem MFC-Buch drin.
Ich selbst habe mir einen ziemlich umfangreichen 2D-LevelEditor programmiert, ohne das ich WinAPI kann. Aber ich weiß wie ein MFC-Programm an sich funktioniert und aufgebaut ist, das hat aber wenig mit Windows zu tun. Wer MFC, Qt o.ä. lernt, bekommt autom. beigebracht wie das Multitasking funktioniert. Ob das jetzt aber speziell Windows ist, interessiert doch letztendlich nicht? Das ist doch gerade der _Sinn_ eines Wrapper! Es soll mir das Leben vereinfachen, eben nicht wissen zu _müssen_ wie Windows, KDE o.ä. arbeitet.
Was aber nicht heißt, das man sich dafür nicht interessieren soll. Wen es interessiert, kann das ja immer noch genauer erforschen. Aber will das der Fragesteller? Ich denke nicht! Er will sich nicht mit der WinAPI rumschlagen, genauso wenig wie ich. Ich will meine Anwendung programmieren und sie soll am Ende funktionieren. Fertig!
[ Dieser Beitrag wurde am 23.04.2003 um 15:17 Uhr von Artchi editiert. ]
-
Hallo?
hört mir jemand zu?
ich sagte ja: es ist nicht wichtig dass man winAPI kann, sondern dass man versteht was los ist.
bei der MFC wird einem das aufgezwungen - aber zB bei der VCL nicht.
ja sicher, gute bücher erklären die hintergründe - aber viel zuwenig leute lesen bücher. die lesen immer nur tutorials - und da stehts nicht drinnen...
wenn man sagt: lern n bisschen winapi, dann MUSS man sich mit den hintergründen beschäftigen. deshalb schlage ich das immer vor.
denn wenn ich sage: lern mal die hintergründe zu verstehen, dann denken sich viele: pah, graue theorie will ich nicht.
und schon wird die theorie ausser acht gelassen.wenn man aber sagt, programmiere mal nen texteditor in purer winapi, dann ist das interessant und vielleicht auch lustig. aber auf jedenfall beschäftigt man sich dann mit den hintergründen!
-
Original erstellt von Shade Of Mine:
Oder kennst du eine Möglichkeit ohne VC++ vernünftig MFC zu programmieren??Äh, ja. Borland aber der kostet auch Geld. Aber darf ich dich auch was fragen?
Kennst du eine Möglichkeit ohne VC++ vernünftig QT unter Windows zu programmieren??Ich nicht:
The Qt Non Commercial Edition for Microsoft Windows is a binary only distribution requiring Microsoft Visual Studio version 6.
We have no plans to support other compilers
http://www.trolltech.com/download/qt/noncomm.htmlUnd genau auf den Sachverhalt wollte ich mit dem MFC-Verlgeich hinweisen, denn du benötigst sowohl für MFC als auch für QT nunmal den VC++
-
Original erstellt von sarfuan:
Und genau auf den Sachverhalt wollte ich mit dem MFC-Verlgeich hinweisen, denn du benötigst sowohl für MFC als auch für QT nunmal den VC++ich behaupte mal, dass es möglich ist jeden zum VC++ binary kompatiblen compiler dazu zu bringen Qt zu unterstützen.
Ich habs noch nicht probiert, aber zB dmc++ kann MFC Anwendungen kompilieren und ist binary kompatibel zum VC++ - da bekommt man Qt wahrscheinlich zum laufen
-
Bietet Borland denn die MFC an? Ich hab noch nie die IDE von Borland benutzt, kann also hier nur vermuten. Aber MFC ist soweit ich weiß nur von MS direkt erhältlich. Andere Compiler dürften da so ihre Schwierigkeiten haben.
-
Bietet Borland denn die MFC an?
ja
-
Original erstellt von Shade Of Mine:
**ich behaupte mal, dass es möglich ist jeden zum VC++ binary kompatiblen compiler dazu zu bringen Qt zu unterstützen.Ich habs noch nicht probiert, aber zB dmc++ kann MFC Anwendungen kompilieren und ist binary kompatibel zum VC++ - da bekommt man Qt wahrscheinlich zum laufen ;)**
Tja, was meine ursprüngliche Aussage, QT sei genauso kostenlos wie MFC nur weiter untermauert
-
*g*... bevor das noch zum flame ausartet:
hab mich entschlossen (und auch schon damit angefangen) etwas WinAPI zu lernen... Shade of Mine's Argumentation hat mich ueberzeugt... und so schlimm find ich das ganze bisher nicht *g*
Aber was danach? MFC wollt ich sowieso nie lernen, hab schon oefters gehoert die soll nicht sonderlich gut (sprich: kein gutes OOP, sondern ziemlich konfus) programmiert sein, ausserdem faend ich's super dass ich, wenn ich spaeter mal Linux-Programme coden will, das machen kann ohne mich gross in eine neue API einzuarbeiten...
Bleiben also anscheinend nur noch wxWindows und QT (oder ist GTK+ auch fuer Windows gut - afaik ist das nur fuer X, oder?).... welche der beiden Wrapper ist denn besser?
QT hab ich mir noch net so angeschaut, aber wxWindows gefaellt mir nicht schlecht... Lizenz ist der LGPL aehnlich, recht gut dokumentiert (soweit ich das bisher ueberblicke), kaum Unterschiede ob ich jetzt fuer Windows oder fuer Linux code... eure Meinung?
Was den Compiler angeht: ich bin am ueberlegen mir die Studentenversion vom Visual Studio zu holen (eh nicht so teuer)... damit laeuft MFC ja sowieso, QT auch und ich schaetze wxWindows sicher auch.... momentan hab ich sowohl das Working-Model vom VC++ als auch Dev-C++ und den BCC 5.5 auf der Platte...
-
Wie wäre es mit GTKmm ? http://gtkmm.sourceforge.net/index.shtml
wxWindows ist mit MinGW (DevC++) imho nicht wirklich brauchbar, da die dort produzierten ausführbaren Dateien relativ groß sind.
-
Der historische Weg ist der Interessanteste. Daher mit WinAPI/C beginnen. Das zahlt sich später aus.
[ Dieser Beitrag wurde am 28.04.2003 um 20:45 Uhr von Erhard Henkes editiert. ]
-
Der historische Weg ist der Interessanteste. Daher mit WinAPI/C beginnen. Das zahlt sich später aus.
kann ich nur zustimmen ...
rocknix ///
-
Original erstellt von Blue-Tiger:
[...]ausserdem faend ich's super dass ich, wenn ich spaeter mal Linux-Programme coden will, das machen kann ohne mich gross in eine neue API einzuarbeiten...[...]Aaaaalso, muss ich doch auch noch was dazu husten (o:
a) alle Systeme kochen mit Wasser. Will heissen, dass auch in der X-Window Umgebung messages versendet werden etc. Vielleicht heissen die Aufrufe anders, aber das System bleibt annähernd das Selbe.
b) Du hast was vergessen bei den frameworks: die CLX. (Cross-Component Library) von borland. Applikationen die sich auf CLX beschränken können 1:1 von Win nach Lin und umgekehrt übernommen werden... wobei der Haken klar der ist, dass man sich sklavisch daran gehalten hat, API die von der CLX nicht abgedeckt wird zu kapseln.
Wenn du etwas geld investieren willst, kannst du dir die Student-Edition von Borland beziehen. (siehe borland.de für genaueres) die kostet erheblich weniger als die professionellen Versionen, unterliegt aber Einschränkungen in der Weitergabe der Programme (kein Verkauf, etc. auch hier genaueres auf borland.de). Kostenpunkt etwa 10% von der "richtigen" version jeweils.
Gratis gibts alledings den Kylix Open Edition (hald für linux) unterliegt auch gewissen Einschränkungen aber auch hier fällt das Ganze zum "rumspielen" das nicht so ins Gewicht.
Ich persönlich hatte das zweifelhafte Vergnügen einige andere Frameworks zu testen und muss sagen, dass die VCL oder eben die CLX durchaus gut brauchbar sind. QT ist auch nicht schlecht. Hat einfach bezüglich der Implementation klar mehr "Erfahrung" auf dem Buckel als die CLX (o:
(nur um das auch noch in deine Überlegungen eingebracht zu haben.)
-junix