Was bietet Microsoft für native GUI Entwicklung an?
-
Wer sagt denn das MFC tot ist?
Wenn du die offiziellen MSDN- und Channel9-Aussagen lesen und hören würdest, würdest du etwas anderes sagen. MFC wird von MS weiter entwickelt, schon allein deshalb, weil die meiste MS-Software (z.B. das gesamte Office!) mit der MFC entwickelt ist. Und in jedem MSVS gab es bisher MFC-Fortschritte zu sehen. Im kommenden Orcas wirds wieder MFC-Fortschritte bzgl. Vista geben. Würde MS MFC nicht weiter entwickeln, würde ihre eigene Software-Palette darunter leiden. Und diese ebend mal auf eine andere GUI-Library umstellen, wäre nicht sinnvoll (Zeit = Geld).Mit der MFC hat jedenfalls MS eine offizielle GUI-Strategie für unmanaged Code. Weiterhin gibts noch die ATL, mit der man auch noch was reissen kann, die auch weiter entwickelt wird.
Wem das nicht reicht, muß/kann sich bei Drittherstellern umsehen. Und wir müssen hier nicht in jedem Topic immer wieder die nativen/unmanaged Kandidaten nennen, oder? (die übrigens auch MS ein Begriff sind)
-
Naja, aber ich dachte MFC wird in den neuen Visual C++ (2003, 2005, ...) nur noch sporadisch unterstützt?
(Ich hab selber nur den VC++2005 Express, hier gibt's gar keine MFC-Unterstützung, deshalb kann ich das nicht sicher sagen.)
Also klärt mich bitte auf: Kann ich im VC++2005 ein vernünftiges MFC-Projekt hochzimmern, unter zuhilfenahme der ganzen Ressourcen-Editoren usw. und ist das von MS immer noch der vorgeschlagene Weg?
Artchi, Du sagst selber auf deiner GUI-Libs Seite über MFC: "Für neue Projekte nicht zu empfehlen.". Wieso denn dann?
-
scrontch schrieb:
(Ich hab selber nur den VC++2005 Express, hier gibt's gar keine MFC-Unterstützung, deshalb kann ich das nicht sicher sagen.)
mfc ist nur in den bezahle-versionen vom vs enthalten...
scrontch schrieb:
Also klärt mich bitte auf: Kann ich im VC++2005 ein vernünftiges MFC-Projekt hochzimmern, unter zuhilfenahme der ganzen Ressourcen-Editoren usw. und ist das von MS immer noch der vorgeschlagene Weg?
ja, es geht noch.
der von M$ vorgeschlagene weg ist, .NET zu benutzen...
-
Der Express Version fehlt so einiges, nicht nur die MFC. Das kannst du also nicht gerade als Grund nennen. Denn der Express fehlen auch andere definitiv wichtige und neue Technologien. Deshalb würde man aber nicht auf die Idee kommen, das sie keine Zukunft haben?
Wenn du die Standard-Edition kaufst, hast du die MFC und ATL und kannst natürlich eine komplette MFC-Infrastruktur nutzen. Mittlerweile kannst du sogar _in_ MFC-Panels WindowsForms-Panels einbetten und so die MFC als Host für WinForms wirken lassen. Mit Orcas werden die neuen Vista-Dialoge usw. (die native Win32-API sind!!!) in der MFC nutzen können.
Das ich die MFC auf meiner Liste für neue Projekte nicht empfehle, ist meine persönliche Meinung. Denn natürlich spiegelt die Liste mit ihren Kommentaren eine gewisse Meinung und Geschmack wieder. Z.B. prangere ich Qt bzw. Trolltech in einem gewissen Maße an... heißt aber deshalb nicht, das Qt von Trolltech nicht mehr entwickelt wird. Auch gtkmm bekommt ein wenig sein Fett weg, genauso wie wxWidgets.
Wenn die MFC von MS nicht mehr weiter gepflegt werden würde (sondern es auslaufen lassen würde), hätte ich es auch reingeschrieben oder sogar die MFC mit einem Vermerk ganz aus der Liste rausgelassen.
Warum ich die MFC für neue Projekte nicht empfehle, steht übrigens auch dabei. Lies den Hinweis einfach nochmal komplett und genau durch.
-
Wenn du eine reine Desktop (Legacy) Anwendung schreibst, gut genug c++ kannst und Wert darauf legst Kontrolle zu haben, Performant und unabhängig von den gefühlten 932 zueinander inkompatiblen Versionen des .net framework zu sein, dann nimm die MFC, besser WTL.
Von WinForms halte ich persönlich gar nichts, ich gelange ab einer gewissen Komplexität der Anwendung immer an einen Punkt, an dem das Zeug Probleme macht, nicht anpassbar genug ist, oder die GC die Anwendungsperformance auffrißt.
Wenn du was Serverseitiges schreibst, ist die Frage nicht so einfach zu beantworten, hier hat .net wirklich viele Vorteile, die einzig bei Anwendungen, die allerhöchste Performance brauchen nicht zum tragen kommen (aber es gibt ja zum Glück CLI/C++ für .net, dass Du sogar frei mixen kannst mit MFC/WTL und co.).
Native C++ Anwendungen sind und bleiben auf dem Desktop das nonplusultra in der Windows-Entwicklung! Nach jetzt gleich 7 Jahren!!! .net gibt es bezeichnenderweise keine einzige große Anwendung (von MS, Adobe, etc), die es ernsthaft einsetzen würde. Das neueste "Vista" besteht zu 99%!!! aus nativen C++ Anwendungen und bringt mehrere tausend neue WinApis mit (entgegen aller Gerüchte, die die .net-Welt so von sich gegeben hat O-Ton: "MS wird Windows auf .net Basis entwickeln" -> ROFL, ich warte seit 10 Jahren auf ein OS auf Java oder .net Basis, nur es wird niemals kommen ... ).
Wahre Annekdote: Da die Konfusion durch den Marketinghype auch intern bei MS vorhanden ist, trug eines Tages die VC++-Abteilung spasseshalber T-Shirts, um die C#-Entwickler etwas runterkommen zu lassen mit der Aufschrift
"Hey dude, my compiler compiled yours!"
Es ist ein Irrglaube zu denken, dass MS irgendwann die native Unterstützung für sein eigenes OS aufgeben wird, oder dass sie es mit .net reimplementieren.
Auch werden Sie keinen Entwickler daran hindern das zu tun, dass wäre der letzte Schritt den Linux noch braucht, dass massenhaft professionelle C++Entwickler von MS rüberwechseln.Warum MS per Marketing möglichst viele Entwickler in die .net "Blackbox" schieben will hat seine eigenen Ursachen, die einen eigenen Thread wert sind.
-
Tja, dann vielleicht doch ein anderes plattformunabhängiges Framework?
-
Das mit der .net "Blackbox" würde mich interessieren...
Könntest du vielleicht mehr dazu erzählen ?
[...]hat seine eigenen Ursachen, die einen eigenen Thread wert sind.
Gerne auch im eigenen Thread
-
Ich glaube er meint mit blackbox (im sinne eines flugschreibers, der alles aufzeichnet) die totale kontrolle, die microsoft und jeder der sich auskennt über gemanagten ByteCode/IL hat.
wer mit dotnet programme für windoofclients schreibt kann im prinzip den sourcecode auch offenlegen, die obfuscator etc sind soweit ich weiß nicht ihr geld wert. deswegen gibt es wohl auch (noch?) keine dotnetanwendungen von großen herstellern
Ein weiteres, eigentlich krasses "problem" ist, dass jedes objekt und seine handlungen gemanagt und damit bekannt sind, dies ermöglicht ein problemfreies automatisiertes monitoring (und verhindern von aktionen) zur laufzeit durch das OS, drittsoftware oder remote von einem server aus.
Ich finde eigentlich das hat auch viele vorteile, was sicherheit und wartbarkeit angeht, gebe aber zu, es hat was von "ich stelle weltweit kameras in jeder wohnung auf und behalte mir vor sie auf bedarf per windowsupdate oder sonstwie zu aktivieren", wenn man sicherheitsrelevante daten verarbeitet, sollte man wohl besser drauf verzichten.
(hm wo ich das gerade schreibe, verstehe ich erst glaub ich richtig was gemeint war)
-
-
test215 schrieb:
ich warte seit 10 Jahren auf ein OS auf Java oder .net Basis, nur es wird niemals kommen ... ).
gibs doch schon längst
