Komfortabler Dateimanager mit vielen Funktionen

Weitere Infos zum MFC UI-Update

By Sven on 08.11.2007 - 20:14 in MFC, Visual Studio 2008

Im Codejock-Forum hat Kirk Stowell (der Chef von Codejock) ein paar interessante Infos zur ganzen Geschichte veröffentlicht, die ich euch nicht vorenthalten möchte. Demnach hat Microsoft schon vor einigen Jahren Codejock kontaktiert, um die MFC für Visual Studio 2005 etwas aufzupeppen. Es gab ein paar Gespräche, zu mehr führte es aber nicht.

Im März dieses Jahres ist Microsoft erneut mit Codejock in Kontakt getreten und hat Interesse daran geäußert, Codejocks MFC-Komponenten in die MFC von Visual Studio 2008 aufzunehmen. Das Budget für mögliche Lizenzgebühren sei aber nicht gerade hoch.

Im August ließ Microsoft wieder von sich hören. Man wollte mit Codejock über Erweiterungspläne der MFC diskutieren, als auch über die möglichen Auswirkungen auf die MFC-Produkte von Codejock. In diesen Gesprächen kam herüber, dass Microsoft für wenig Geld die MFC-Komponenten von BCGSoft lizenzieren wird und diese somit Teil der MFC werden sollen.

Kirk gab zu bedenken, dass sich diese Entscheidung als großer Fehler herausstellen könnte. Aus Erfahrung gäbe es einige Probleme mit den BCG-Komponenten, angefangen von der Stabilität bis hin zur recht schwachen Performance. Er wies Microsoft auch darauf hin, dass sich gerade deshalb viele BCG-Anwender für einen Wechsel zu den Produkten von Codejock entschieden hätten und schlug vor, dass Microsoft doch die Meinung einiger dieser Kunden einholen könnte. Der Vertrag mit BCGSoft war aber schon unterschrieben und Microsoft sah keine Notwendigkeit mehr, diese Sache weiter zu verfolgen.

Genau wie Kirk glaube ich auch, dass Microsoft eine ziemlich unglückliche Entscheidung getroffen hat. Die Performance-Probleme waren damals auch einer der Gründe für mich, vor vier Jahren zu Codejock zu wechseln. Ich kann mich noch gut daran erinnern, dass die Einbindung der BCGControlBar in FileSearch (SpeedCommander 9) den Start der Anwendung um knapp zwei Sekunden verzögerte. Also verzichtete ich damals in FileSearch auf die anpassbaren Menüs, stattdessen zeigte sich FileSearch nur mit normalen Menüs.

Gemeinsam mit Rainer haben wir damals auch die Aufrufgeschwindigkeit der frei downloadbaren Beispieldateien von Codejock und BCGSoft miteinander verglichen. Die von BCGSoft starteten alle merklich langsamer. Auf Rainers Rechner, der damals auch nicht gerade der schnellste war, wurde dies besonders deutlich.

Microsoft wird also einiges an Mühe aufwenden müssen, damit die MFCnext ein stabiles und performantes Produkt wird. Es ist als Entwickler immer schwer, sich in eine so umfangreiche Bibliothek einzuarbeiten. Mal schauen, wie Microsoft das meistern wird.

Es gibt 7 Kommentare zu diesem Beitrag

Trackback URL | RSS-Feed für Kommentare

Folgende Seiten verlinken zu diesem Beitrag:

  1. Techy News » Blog Archive » Weitere Infos zum MFC UI-Update | 08.11.2007
  1. Das wird wohl auch der Grund für den 50% Rabatt gewesen sein 😉
    Hoffentlich spart MS da mal nicht an der falschen Stelle…

  2. Sven sagt:

    Ja, jetzt macht der 50% Rabatt auch irgendwie Sinn. 🙂

  3. Michael Külshammer sagt:

    Die haben den ganzen Ribbon-Quatsch tatsächlich schon ins MFC eingebaut:

    mms://mschnlnine.wmod.llnwd.net/a1809/d1/ch9/0/MFC_NextGen_s_ch9.wmv

    oder hier, falls der obige Link nicht funktionieren sollte:

    http://channel9.msdn.com/showpost.aspx?postid=355087

    D.h. die ganze Oberflächenstrickerei mit BCG seit Jahren wird nun einfach mal kurz in die MFC eingebaut. Das sind ja vielleicht Neuigkeiten.

    In dem Video tut Microsoft doch tatsächlich so, als hätten sie das alles selbst programmiert.

    Die Performance-Probleme stimmen so nicht, BCGControlbar Professional-Programme starten genauso schnell, siehe auch, wie schnell das Starten im Video geht. Hängt wohl nur von der Schnelligkeit des Rechners ab, wie schnell irgendwas startet. Aber für Vista braucht man ja auch schon Wahnsinnsrechnerleistungen.

    Warum nicht die Codejock-Library integriert wurde, keine Ahnung, da ich aber seit Jahren keine Lust habe, meine mit der BCG-Library gestrickten Oberflächen durch die Codejock-Oberfläche zu ersetzen, bin ich einfach nur aus Faulheit, weil es eben nicht nur auf die Oberläche ankommt, sondern auf die Funktion des Programmes, das man schreibt, bei BCGSoft geblieben. Ich schaue aber manchmal etwas neidisch, da ich den ComponentSource-Newsletter habe, wie schnell Codejock immer wieder Updates herausschießt, und wieviel mehr Kontrollelemente (z. B. bei dialogbasierten Programmen) es doch bei Codejock gibt, als bei BCGSoft. Codejock hat wesentlich mehr Kontrollelemente als BCGSoft, bei Codejock scheinen auch mehr Entwickler am Werk zu sein als bei BCGSoft. Meines Erachtens hätte Microsoft daher die Codejock-Library nehmen müssen, wegen den wesentlich mehr Funktionen, Kontrollelementen , etc. Zum Glück benutze ich diese Ribbonbars sowieso nicht, d. h. ob die nun im neuen MFC drin sind oder nicht, ist mir eigentlich ziemlich egal. Was nun letztendlich den Ausschlag für BCGSoft und gegen Codejock gab, wird sicherlich nicht mehr von Microsoft bekanntgegeben. Es läßt sich wohl nichts mehr ändern. Ich kenne auch die Macken der BCG-Library, daher mache ich mir so meine eigenen Gedanken. Aber Performance-Probleme sind sicherlich nicht die Probleme, die ich mit der BCGSoft-Library habe.

    Codejock hin-, BCGSoft her, wie dem auch sei, es bleibt ja jedem weiterhin freigestellt, auch weiterhin die Oberflächen-Library seiner Wahl zu verwenden. Statt diesem ganzen komischen Ribbonbar-Zeugs sollten sich die MFC-Programmierer von Microsoft lieber darum kümmern, mehr Kontrollelemente zu entwickeln, die man per Drag und Drop auf Dialogboxen ziehen kann, damit man nicht alles immer und immer wieder mit abgeleiteten Klassen von Standard-Kontrollelementen machen muß, z. B. farbige Dialoge, Skins, farbige Buttons, vernünftige Excel-Gitterkomponenten etc., wie es sie in den .NET-Sprachen so schön einfach gibt. Auch eine GDI+-Implementation oder -Anpassung wäre nicht schlecht, XML-Parser-Klassen etc., wer schon mal Farbverläufe oder ähnliches mit MFC programmieren mußte, oder Einlese-Routinen für verschiedene Bilddatei-Formate, wird mir beipflichten, in .NET gibt es für das alles fertige Klassen, das ist manchmal traurig, wenn man das alles sieht, was man in MFC mühsam programmieren oder zusammenlinken muß, und was es in .NET so schön einfach gibt, auch Excel- und Word-Ansteuerungen sind in .NET ein Kinderspiel.

    Vielen Dank für die Info !!

    Abschließend ebenfalls vielen Dank an Sven für dieses Blog, was seit Monaten immer wieder sehr interessant zu lesen ist.

    Tschüs,
    Michael Külshammer

  4. Michael Külshammer sagt:

    Ich frage mich auch, warum Microsoft überhaupt eine externe Library für die Oberflächen-Gestaltung von Programmen in MFC einbauen muß, da Microsoft ja eigentlich genau wissen müßte, wie Ribbon-Symbolleisten programmiert werden müssen, da sie ja von Microsoft erfunden und in Office 2007 von Microsoft höchstpersönlich implementiert wurden.
    Auch Docking Panels, Rein-/Rausfahren von Control-Panels ist ja schon in Visual Studio integriert, also auch von Microsoft entwickelt, daher müßte Microsoft ja schon den kompletten Sourcecode für diese ganzen Oberflächen-Gimmicks haben, und ich nehme auch an, dass das Ganze in C++ geschrieben ist, warum also mußte Microsoft überhaupt noch eine externe Library hinzukaufen, vielleicht deswegen, weil der von Microsoft selbstentwickelte Oberflächen-Schnickschnack nicht in MFC geschrieben (gekapselt) ist ?? Ich habe keine Ahnung, warum überhaupt die Notwendigkeit für Microsoft bestand, sich eine externe Oberflächen-Bibliothek hinzuzukaufen.

    Michael Külshammer

  5. Sven sagt:

    Mittlerweile gibt es auch eine Presseerklärung von BCGSoft:

    http://www.bcgsoft.com/pressreleases/PR071110.pdf

    Ich hoffe ja nur, dass die “neue” MFC nicht mit der alten zusammengeführt und nur als zusätzliche Bibliothek ausgeliefert wird.

    @Michael: Die Portierung nach Codejock war bei mir nicht so aufwendig. Ich fand sogar, dass der Code anschließend um einiges schlanker war. Zum Speichern der Einstellungen als XML-Dateien gibt es bei Codejock ein nettes System, über das ich hier schon mal berichtet habe.

  6. Rainer Schuster sagt:

    Na ich will ja jetzt nicht schlechte Laune verbreiten, aber ich bin der Meinung das die MFC ruhig aussterben darf. Unser jetziges Produkt benutzt im Verbund mit 2 Millionen Zeilen FoxPro-Code auch nochmal genausoviel C++ und MFC. Ich bin froh, wenn ich keine Zeile MFC mehr schreiben muss.

Top