Hallo, ich versuche mit VS 2010 eine einfache MFC Anwendung zu bauen. Aber mit der neusten Version von Visual Studio wurden viele der althergebrachten Konzepte über den Haufen geworfen und vieles hat sich verändert. Schade nur, dass es dadurch nicht mehr ganz so einfach ist wie früher, eine Anwendung zu entwickeln. Meine Frage deshalb: kennt ihr vielleicht ein Tutorial oder sonst eine Anleitung, wo Schritt für Schritt beschrieben wird, wie man mit VS2010 eine MFC Anwendung entwickelt?
:
Verschoben durch Admin
http://msdn.microsoft.com/library/e6w9eycd(VS.100).aspx oder wenn's Videos sein sollen http://msdn.microsoft.com/en-us/visualc/bb496952.aspx p.s. was hat sich da gegenüber der 2008er oder 2005er so stark verändert? Unter der Haube ja, bei der Oberfläche eher wenig.
Arc Net, naja, wie z.B. eine Toolbar mit Icons mit > 16 Farben gemacht wird, finde ich nicht so selbsterklärend. Und auch, wie diese Docking-Windows erstellt werden, erschliesst sich mir noch nicht so ganz. Lässt man vom Anwendungs-Assistenten eine MDI-Anwendung erstellen, dann klappt das zwar wunderbar, aber es werden seeeehr viele Ressourcen erzeugt im Ressourcen-Editor, aber es ist nirgends beschrieben, wozu die alle gebraucht werden und wie und ob man die editieren soll.
Wenn du was ordentliches willst und dazu auch brauchbare Doku erwartest, dann kannst du dir mal Qt anschauen. Das erscheint mir wesentlich angenehmer zu verwenden und vor allem logischer als MFC und ähnliche Chaossysteme, zudem ist alles ordentlich beschrieben und es gibt viele Beispiele (auch ganz einfache zum Einstieg).
<Sarkasmus> Und jetzt unterstell doch bitte jemand dem Klaus, er habe keine Ahnung </Sarkasmus> Ich schließe mich dem voll und ganz an. Vielleicht beruhigt sich das bei MS irgendwann mal wieder, aber momentan kommt man sich da vor, wie ein Versuchskaninchen.
Gebt doch zu, dass ihr nur deshalb zu Qt ratet, weil es einfach uncool ist, Microsoft Software zu verwenden. Ich für meinen Teil mag dieses Unix-Zeug gar nicht. Und von da her kommt Qt schliesslich.... Womit ich nicht sage, dass Windows besser ist. Trotzdem kringeln sich mir die Zehennägel hoch, wenn ich schon nur mal den Sourcecode von diesem Opensource-Kram anschaue. Da zeigt sich jeweils deutlich: was nichts kostet, ist in der Regel auch nicht viel Wert. Ich bin ein eifriger Benutzer des PC-Lint, vielleicht kennt ihr den? Wenn ich einen Sourcecode von Sourceforge oder ähnliches mal durch den PC-Lint lasse, sträuben sich mir die Nackenhaare ab dieser Menge von Fehlermeldungen. Bei Qt wird das nicht anders sein - unbrauchbar. MFC ist auch nicht gut, aber wenigstens nicht so ein gebastel.
Qt ist zwar von Trolltech, aber DICH hat man damit bestimmt nicht gerufen.
Klaus Wachtler schrieb: > Wenn du was ordentliches willst und dazu auch brauchbare Doku > erwartest, dann kannst du dir mal Qt anschauen. QML/Qt Quick oder doch lieber Standard-Qt > Das erscheint mir wesentlich angenehmer zu verwenden und vor > allem logischer als MFC und ähnliche Chaossysteme, zudem ist > alles ordentlich beschrieben und es gibt viele Beispiele > (auch ganz einfache zum Einstieg). Dann einfach mal den Links von oben folgen...sowas gibt's für Qt nicht. http://developer.qt.nokia.com/wiki/Category:Developing_with_Qt und http://doc.qt.nokia.com/4.7/index.html vs. http://msdn.microsoft.com/en-us oder http://msdn.microsoft.com/en-us/ff380143 oder http://msdn.microsoft.com/en-us/library/ms754130.aspx (WPF) oder http://msdn.microsoft.com/en-us/vcsharp/aa336766 oder ... <flame> da sich Nokia mittlerweile für etwas anderes entschieden hat, dürfte auch deren Qt-Unterstützung abnehmen </flame>
Tobias Plüss schrieb: > ich versuche mit VS 2010 eine einfache MFC Anwendung zu bauen. Mal zurück zum Anfang. Gibt es einen besonderen Grund, weshalb es ausgerechnet MFC sein soll? VS2010 beherrscht modernere Techniken, die viel leichter zu handhaben sind (C#, .NET, WPF, um nur ein paar zu nennen).
Arc Net schrieb: > da sich Nokia mittlerweile für etwas anderes entschieden hat, dürfte > auch deren Qt-Unterstützung abnehmen Ich würde eher vermuten, dass Nokia genug Geld mit Qt verdient. MeeGo spielt da zwar auch rein, aber Trolltech konnte gut mit Qt wirtschaften und Nokia sollte das auch hin bekommen. Klaus Wachtler schrieb: > Wen interessiert Nokia? Das bezieht sich wohl darauf, dass Trolltech von Nokia gekauft wurde. Für den Fall, dass der Elop Qt einstampft, würde ich davon ausgehen, dass es ein Trolltech-NG geben würde. Es gibt ja immer noch die "Absicherung über die KDE Free Qt Foundation", abgesehen davon, dass Qt sowieso größtenteils unter LPGL lizensiert ist. Ich würde auch Qt nehmen, der QtCreator ist eine feine IDE und ansonsten kannst du mit google und Co. auch auf eine andere IDE wechseln, z.B. Visual Studio, Code::Blocks...
ole schrieb: > Klaus Wachtler schrieb: >> Wen interessiert Nokia? > Das bezieht sich wohl darauf, dass Trolltech von Nokia gekauft wurde. > Für den Fall, dass der Elop Qt einstampft, würde ich davon ausgehen, > dass es ein Trolltech-NG geben würde. Es gibt ja immer noch die > "Absicherung über die KDE Free Qt Foundation", abgesehen davon, dass Qt > sowieso größtenteils unter LPGL lizensiert ist. Genauso meinte ich das auch. Qt hängt nicht unbedingt von Nokia ab.
Klaus Wachtler schrieb: > ole schrieb: >> Klaus Wachtler schrieb: >>> Wen interessiert Nokia? >> Das bezieht sich wohl darauf, dass Trolltech von Nokia gekauft wurde. >> Für den Fall, dass der Elop Qt einstampft, würde ich davon ausgehen, >> dass es ein Trolltech-NG geben würde. Es gibt ja immer noch die >> "Absicherung über die KDE Free Qt Foundation", abgesehen davon, dass Qt >> sowieso größtenteils unter LPGL lizensiert ist. > Genauso meinte ich das auch. Qt hängt nicht unbedingt von Nokia ab. Okay, dann habe ich das wohl falsch verstanden... ;-)
besucher schrieb: > Mal zurück zum Anfang. Gibt es einen besonderen Grund, weshalb es > ausgerechnet MFC sein soll? VS2010 beherrscht modernere Techniken, die > viel leichter zu handhaben sind (C#, .NET, WPF, um nur ein paar zu > nennen). MFC ist die einzige, die C++ verwendet. Alle anderen setzen auf dem .Net-Geraffel auf. Wenn man das will, wenn man sich der Einschränkungen bewusst ist, die das mit sich bringt, bitte. Nur zu. (Nicht, daß ich die MFC Einsteigern nahelegen würde. Wirklich nicht, da haben andere Töchter deutlich schönere Mütter)
Rufus Τ. Firefly schrieb: > MFC ist die einzige, die C++ verwendet. In diesem Thread steht nirgendwo, dass es C++ sein muss. Rufus Τ. Firefly schrieb: > Alle anderen setzen auf dem .Net-Geraffel auf. > Wenn man das will, wenn man sich der Einschränkungen > bewusst ist, die das mit sich bringt, bitte. Ich kann absolut nicht behaupten, dass ich das .NET-"Geraffel" als Einschränkung empfinde. Im Gegenteil.
besucher schrieb: > In diesem Thread steht nirgendwo, dass es C++ sein muss. Nein. Aber... Tobias Plüss schrieb: > kennt ihr vielleicht ein Tutorial oder sonst eine Anleitung, wo Schritt > für Schritt beschrieben wird, wie man mit VS2010 eine MFC Anwendung > entwickelt? ... die Ausgangsfrage des TO war nach MFC mit VS2010. Was wiederum C++ impliziert, oder? Gruß Markus
besucher schrieb: > In diesem Thread steht nirgendwo, dass es C++ sein muss. Das ist korrekt. Nur gibt es tatsächlich Leute auf diesem Planeten, die in C++ programmieren wollen; die Erwähnung der MFC kann als Indiz dafür gewertet werden. besucher schrieb: > Ich kann absolut nicht behaupten, dass ich das .NET-"Geraffel" als > Einschränkung empfinde. Im Gegenteil. Diese Diskussion wurde hier bereits ad nauseam geführt. Mit dem Wissen, wie mit dem .Net-Geraffel umgegangen wird, kann man auf anderen Plattformen, die keine .Net-Unterstützung bieten, nichts anfangen. Wer nie gelernt hat, mit Pointern umzugehen (und das lernt man bei .Net nicht), der wird, wenn er denn mal mit einem µC hantieren muss, verzweifeln. Bei Leuten, die sich in diesem Forum herumtreiben, davon auszugehen, daß sie möglicherweise auch ihre Programmierkenntnisse auf µCs anwenden wollen, ist nicht völlig abwegig. Wenn Du mit der schönen neuen MS-Welt glücklich bist, bitte. Will ich Dir nicht nehmen.
Markus Volz schrieb: > ... die Ausgangsfrage des TO war nach MFC mit VS2010. > Was wiederum C++ impliziert, oder? Nicht zwingend. Mit derselben Logik könnte man nämlich auch fragen, wieso jemand weiter oben Qt empfohlen hat.
Hallo, ohje, da habe ich wohl wieder einmal einen Glaubenskrieg losgetreten. Eigentlich schade, dass bei der Erwähnung des Ausdrucks MFC gleich immer die ganze Opensource-Gemeinde daher kommt und das MFC-Bashing beginnt. Seit der Einführung der MFC ist diese verpönt, und niemand gibt zu, sie zu benutzen, und es hält sich auch hartnäckig das Gerücht, sie würde demnächst mal aussterben. Interessanterweise wird das Zeug aber immer noch weiter entwickelt. .NET ist gut und recht, es ist wunderbar einfach, ein Programm damit zu entwickeln. Aber das werden immer sooooo riesige, aufgebalsene Dateien, und was mich am meisten stört daran, ist, dass zum Ausführen einer .NET-Anwendung auch das .NET-Framework installiert werden muss. Ich kann beim besten willen nicht einsehen, wieso ich zu einem Programm, das 100 kB gross ist, eine Runtime installieren sollte, die mehrere 10 MB gross ist (kenne den genauen Wert jetzt nicht). Ausserdem ist .NET langsam; MFC wird zu richtigem, "echten" Maschinencode compiliert und lässt sich optimieren - daher ergibt das eine schnelle und schlanke Anwendung. Rufus hatte auch recht mit seiner Aussage, dass ich C++ benutzen will. Deshalb die Frage nach der MFC...
Rufus Τ. Firefly schrieb: > Diese Diskussion wurde hier bereits ad nauseam geführt. Ich will sie auch nicht wieder anfangen. Ich weise nur auf die Möglichkeit hin. Oder geht selbst das schon zu weit? > Mit dem Wissen, > wie mit dem .Net-Geraffel umgegangen wird, kann man auf anderen > Plattformen, die keine .Net-Unterstützung bieten, nichts anfangen. Wer > nie gelernt hat, mit Pointern umzugehen (und das lernt man bei .Net > nicht), der wird, wenn er denn mal mit einem µC hantieren muss, > verzweifeln. Bei Leuten, die sich in diesem Forum herumtreiben, davon > auszugehen, daß sie möglicherweise auch ihre Programmierkenntnisse auf > µCs anwenden wollen, ist nicht völlig abwegig. Genausowenig abwegig ist, dass jemand mehrere Sprachen und Entwicklungssysteme kennen will, um im konkreten Fall das am besten passende auswählen zu können. Halte ich persönlich für eine durchaus professionelle Einstellung.
Tobias Plüss schrieb: > Rufus hatte auch recht mit seiner Aussage, dass ich C++ benutzen will. > Deshalb die Frage nach der MFC... OK. Dann viel Spaß damit. Ich bin froh, dass ich MFC nicht mehr benutzen muss und kann dir daher nicht weiterhelfen. :)
Ich benutze ein noch viel "verpönnteres" Framework: VCL. Finde ich persönlich von allen Frameworks, die ich bisher kenngelernt habe (MFC, VCL, NET, Swing, SWT), immer noch am besten. Wenn meine Kollegen immer von NET schwärmen, wie toll doch damit Oberflächen entworfen werden können, sage ich immer: Ja sicher, aber sowas ist mit der VCL schon seit 1996 genauso einfach möglich. Aber davon wollen die dann immer nix wissen, kamen auh schon mit Argumenten, das sie ja bei der VCL gar nicht nachvollziehen können, wie das ganze verwaltet wird (obwohl die VCL auch als Quellcode verfügbar), eigenartigerweise stört sie das bei NET aber nicht.
besucher, du musst hier auch nicht posten, wenn du die Antwort auf die Frage nicht weisst. Die Frage ist klar formuliert: gibts eine Step by Step Anleitung? Mit der MFC, die bei Visual Studio 2008 und früher verwendet wird, komme ich gut klar, aber die neue Version bietet ziemlich viele neue Features, bei denen ich gerne wüsste, wie man die korrekt anwendet. Warum postest du hier, wenn du nichts zum Thema beitragen kannst? Ich bin übrigens der Ansicht, dass das .NET Geraffel durchaus seine Daseinsberechtigung hat. Wenn ich mir "mal eben schnell irgend ein Tool" basteln will, um etwas zu automatisieren, dann benutze ich dazu schon mal .NET. Aber bitte nicht für ein Programm, das man ernsthaft benutzen möchte - .NET ist zu langsam und verbraucht viel Speicher. Wenn ich hier eine simple .NET-Anwendung mache, die nichts weiter tut, als ein einzelnes Window zu öffnen, dann braucht die gemäss dem Windows Task-Manager bereits 23000k Speicher. Wahnsinn! Dasselbe in MFC braucht einige 10k. Das Argument, dass man heute genug Speicher hat, ist nicht ein gutes Argument; man sollte Software eigentlich so schreiben, dass sie möglichst schnell ist und möglichst wenig Speicher verbraucht - und da ist .NET eben nicht geeignet.
Tobias Plüss schrieb: > Eigentlich schade, dass bei der Erwähnung des Ausdrucks MFC gleich immer > die ganze Opensource-Gemeinde daher kommt und das MFC-Bashing beginnt. Ich gehöre nicht zur Opensource-Gemeinde, ich verdiene seit über 15 Jahren mein Geld mit MFC-Anwendungen. Daher lehne ich mich nicht zu weit aus dem Fenster, wenn ich schreibe, daß ich die MFC kenne. Gut kenne. Und genau deswegen empfehle ich sie Programmieranfängern nicht. Einerseits ist die MFC windowszentrisches Inselwissen, was sich anzueignen ich heutzutage keinem Entwickler mehr raten würde, andererseits gibt es bessere, umfangreichere und erheblich besser dokumentierte andere Klassenbibliotheken. Sich in eine Klassenbibliothek dieser Größenordnung einzuarbeiten ist kein Wochenendunterfangen, und wenn man den Aufriss eh betreibt, dann kann man sich auch etwas zu Gemüte führen, das einem Möglichkeiten auch für andere Betriebssysteme nicht verschließt. wxWidgets und Qt machen ähnliche Dinge wie die MFC, sind aber eben nicht nur unter Windows, sondern unter einer großen Anzahl anderer Systemumgebungen nutzbar - auch im embedded-Bereich.
Rufus, ich kenne die MFC auch. Nicht so gut wie du, aber ich bin imstande, damit was zu programmieren. Aber eben noch nicht mit der allerneusten Version....
rogie schrieb: > Ich benutze ein noch viel "verpönnteres" Framework: VCL. > > Finde ich persönlich von allen Frameworks, die ich bisher kenngelernt > habe (MFC, VCL, NET, Swing, SWT), immer noch am besten. Wenn meine > Kollegen immer von NET schwärmen, wie toll doch damit Oberflächen > entworfen werden können, sage ich immer: Ja sicher, aber sowas ist mit > der VCL schon seit 1996 genauso einfach möglich. Aber davon wollen die > dann immer nix wissen, kamen auh schon mit Argumenten, das sie ja bei > der VCL gar nicht nachvollziehen können, wie das ganze verwaltet wird > (obwohl die VCL auch als Quellcode verfügbar), eigenartigerweise stört > sie das bei NET aber nicht. Der Entwickler der VCL arbeitet seit längerem bei Microsoft und hat dort das NET-Framework entwickelt. Ich habe bisher auch mit der VCL gearbeitet und fand mich in .NET auf Anhieb zurecht.
Tobias Plüss schrieb: > Ich bin übrigens der Ansicht, dass das .NET Geraffel durchaus seine > Daseinsberechtigung hat. Wenn ich mir "mal eben schnell irgend ein Tool" > basteln will, um etwas zu automatisieren, dann benutze ich dazu schon > mal .NET. Aber bitte nicht für ein Programm, das man ernsthaft benutzen > möchte - .NET ist zu langsam und verbraucht viel Speicher. Immer diese Märchen... Wenn man's richtig macht, ist der Unterschied vernachlässigbar. > Wenn ich hier eine simple .NET-Anwendung mache, die nichts weiter tut, > als ein einzelnes Window zu öffnen, dann braucht die gemäss dem Windows > Task-Manager bereits 23000k Speicher. Wahnsinn! Dasselbe in MFC braucht > einige 10k. > Das Argument, dass man heute genug Speicher hat, ist nicht ein gutes > Argument; man sollte Software eigentlich so schreiben, dass sie > möglichst schnell ist und möglichst wenig Speicher verbraucht - und da > ist .NET eben nicht geeignet. Deshalb laufen auch die meisten Programme unter WP7 (Silverlight, XNA) mindestens ebenso flüssig wie Vergleichbares auf gleichstarken oder leistungsstärkeren Geräten die mit nativem Code gefüttert wurden.
Tobias Plüss schrieb: > Warum postest du hier, wenn du nichts zum Thema beitragen kannst? > > Ich bin übrigens der Ansicht, dass das .NET Geraffel ... Warum postest du deine Meinung über das .NET-Geraffel? Trägt das etwa zum Thema bei ... und wech.
Klaus Skibowski schrieb: > Der Entwickler der VCL arbeitet seit längerem bei Microsoft und hat dort > das NET-Framework entwickelt. Ich habe bisher auch mit der VCL > gearbeitet und > fand mich in .NET auf Anhieb zurecht. Tue ich auch, finde NET ja auch nicht schlecht, nur arbeite halt lieber mit der VCL ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.