starte gerade ein groesseres Projekt, und ueberlege, ob ich's zur Abwechslung mal mit der MFC probieren sollte, da sie von vielen Pros fuer die Windows-Programmierung genutzt wird. Nun sehe ich aber keine Vorteile gegenueber der direkten Programmierung mit der WinAPI, eher im Gegenteil (unuebersichtlich, sehr viel unnuetzes (?) Zeugs usw.). Kann mir jemand die Vorteile/Nachteile gegenueber der WinAPI nennen?

Danke und Gruß
Lucas

wenn dir persönlich die WIN-API besser liegt dann bleib doch dabei. zumindest sollange es um das project geht. ich würde jetzt nicht wechseln da ich mich im MFC besser auskenn als in WIN-API somit würde es mir warscheinlich mehr probleme bereiten mich in WIN_API einzuarbeiten als die auf mich zukommenden probleme mit dem MFC zu lösen.

sich einarbeiten würde ich machen wenn ich kein project for mir hätte.

mfg;)
LowFly

Aber ist wohl auch ein wenig Geschmacksache, wie es mein vorredner schon erwähnt hat.

Grüssli

Mit der Win32 API ist es ohne Verwendung guter Bibliotheken sehr mühsam große GUI Lastige Programme zu erzeugen.

Alleine was die MFC schon an Toolbar Support, Menu, Command Routing bietet ist extrem. Wenn man dann noch Bibliotheken wie Prof-UI, Codejock, oder die BCG Lib verwendet werden luxuriöse GUIs ein Kinderspiel.

Ohne RAD wird heutezutage sowieso kein großes Projekt erstellt.
VS nimmt einem da sehr viel ab was man mit der WINAPI alles selbst erstellen muss.

Die MFC ist nur eine WRAPPERKLASSE für die WINAPI.

Das ist sie leider nicht nur.
Die MFC hat ein extremes Eigenleben wenn man mit Features wie Extension DLLs und ähnlichem arbeiten will oder muss.

Sicher. Die Schicht ist sehr dünn und sehr schnell, die um die WinAPI gebaut ist, aber Sie hat eben auch ihre eigenen Sturkturen Richtlinien und Einschränkungen.
Und seid VS2005 mit dem Zwang Manifeste verwenden zu müssen und dem Zwang Side by Side installieren zu müssen (ja ich weiß es gibt Tricks) ist das ganze Eigenleben noch extremer geworden. Ich bin ein MFC Fan, aber diese letzten Schritte gingen mir zu weit. Sicherheit hin und her.

Die MFC ist nur eine WRAPPERKLASSE für die WINAPI.

Die MFC ist erstmal nur ein eigenes API. In der aktuellen Implementierung natürlich ein Wrapper um das Windows API. Das Windows API wird aber bald gedroppt, die MFC aber weiterentwickelt, als Wrapper um .Net. Mit Windows API würde ich kein neues Projekt mehr anfangen.

man kann doch die Erstellung der Manifeste unterdrücken o.? Ich weiss leider nicht mal so richtig was man mit den M. machen kann (o. muss). Und was meinst Du mit side by side Installation?

Und seid VS2005 mit dem Zwang Manifeste verwenden zu müssen und dem Zwang Side by Side installieren zu müssen (ja ich weiß es gibt Tricks) ist das ganze Eigenleben noch extremer geworden. Ich bin ein MFC Fan, aber diese letzten Schritte gingen mir zu weit. Sicherheit hin und her.

Das hat doch nichts mit der MFC zu tun, sondern ist ein neues Feature von Windows! Warum bringt ihr das eigentlich durcheinander? MS versucht aus der DLL-Hölle rauszukommen, und entsprechend wird Windows neu designed. Die C-Runtime hat hier nunmal den Anfang gemacht. Soll heißen, selbst ein einfach "Hello WOrld" in C ist davon betroffen. Es ist einfach ein neu ausgedachtes Deployment-Verfahren. Die MFC ist lediglich davon (ungewollt) mitbetroffen.

Das einzige wo ich MS eins auf die Nüsse geben könnte, ist die idiotische nichtssagende Fehlermeldung die beim Enduser auftaucht, wenn der Entwickler der Software sein Programm nicht ordnungsgemäß an den Enduser weiter gibt. Oder besser gesagt: warum hat MS das Deployment nicht in VS2005 mit eingebaut? Z.B. durch eine Warnung oder gleich im Projekt-Wizard? Dann würden nicht alle meckern, sondern es toll finden.

Also, eine gute Idee von MS, aber schlecht umgesetzt.