Wie MFC lernen?

Ryko

Guten Tag Martin,
Naja die Sprache nicht,aber MFC ist ja ein Framework und man muss ja eben auch lernen damit umzugehen. Hmm also würdest du eher nicht zu MFC raten so wie ich es jetzt herauslese?

Martin Richter

Ich würde Dir nicht raten Schlittschuhfahren zu trainieren wenn Du mal die Tour de France nachfahren willst.

Ich weiß nicht was Du willst... was soll ich Dir da raten?

Ich mag die MFC eigentlich noch immer. Vielleicht auch deswegen, weil ich mich an Ihre Defizite gewöhnt habe.

Die MFC ist schwer und leicht zugleich. Man hat schnellen Erfolg und zaubert schnell was aus dem Hut. Will man spezielles läuft man schnell mal gegen eine Wand und versteht nichts. So wie bei manchen anderen Frameworks auch.
Was die Flexibilität der Oberfläche mit Ribbons/Toolbars/Dockable Windows etc. angeht ist sie schwer zu schlagen.

Aber an ihr scheiden sich auch die Geister.
Für manche ist sie ein Unding, manche finden sie genial.
Ich beteilige mich nicht mehr an der Diskussion. Aber ich weiß auch was ich will und wähle entsprechend meine Werkzeuge.
Ich bin vermutlich kein guter Ratgeber für Anfänger.

Ryko

Okay trotzdem danke für die Auskunft .
Was ich suche ist eben ein UI Framework oder ähnliches,was eben nicht unbedingt eine Runtime oder ähnliches benötigt.Platform übergreifend brauch es nicht sein,da ich eigentlich nur für Windows Programmiere.Sollte nicht all zu kompliziert sein und gut dokumentiert damit man immer nachschlagen kann.

ATL/WTL ist sind nicht gut dokumentiert, bei MFC hält es sich auch arg in Grenzen, da dröselt man schnell in Knowledge-Base-Artikeln rum etc, wenn man kein passendes Buch zur Hand hat, die Feature-Pack-Neuigkeiten muss man sich praktisch komplett per Reeverse-Engineering reinziehen. Quellcode-Anschauen (Wenn man denn die richtige Lizenz für VS hat) bringt auch nix, wenn man nicht zumindest eine mittelmäßige Ahnung von der zugrundeliegenden Win32-API hat (Die aber wiederum recht umfangreich mit Beispielen und allem dokumentiert ist, was wegen der Jahre, die sie auf dem Buckel hat aber auch bitter nötig ist).
Aber wo liegt eigentlich das Problem, eben ein paar dlls mit auszuliefern?

Ryko

Eigentlich ist es ja kein Problem ne DLL mitzuliefern,ist ja ganz normal. Aber bei einem kleinen Tool mit ner popligen UI von ein paar Controls muss man ja nicht unbedingt DLLs mitschleppen,aber vielleicht sehe ich das auch einfach falsch .

Ryko schrieb:

Eigentlich ist es ja kein Problem ne DLL mitzuliefern,ist ja ganz normal. Aber bei einem kleinen Tool mit ner popligen UI von ein paar Controls muss man ja nicht unbedingt DLLs mitschleppen,aber vielleicht sehe ich das auch einfach falsch .

Ja, tust Du.
Selbst ein .NET-Framework installieren zu müssen juckt heutzutage keine Sau mehr. Hatte noch nie Beschwerden deswegen bei tausenden Installationen unserer Software.
Und falls sich doch jemand dagegen streubt? Sein Pech.

Man kann es nicht lernen, es wird benutzt oder nicht.

Testen hilft am Besten...

gruß
K.

Ich hatte hier eben eine richtig lange mathematische Herleitung für Kosten, Nutzen etc. stehen, aber außer dass es verrückt ausgesehen hätte, war das ohne schlecht abzuschätzende Parameter und aufgrund der nicht wettbewerbsorientierten Situation wenig praxisrelevant.
Deshalb gehe ich jetzt folgendermaßen heran:

Wir führen den Selbstwertfaktor X ein, die Wertschätzung der Zeit eines Freundes und die Wertschätzung Deiner eigenen Zeit. Es soll gelten:

W_tf = 1/X * W_th.

Also, die Wertschätzung der Zeit eines Freundes ist 1/X mal so groß wie die Wertschätzung für Deine eigene Zeit.

Wir wollen den Zeitwert von Entwicklung und Nutzung unter Betrachtung von X minimieren.
Der Nutzungszeitwert ist N*W_tf*Installationszeit, mit N der Anzahl Deiner Freunde. Der Entwicklungszeitwert entspricht W_th*Entwicklungszeit.

Nun müssen wir einen Zusammenhang zwischen Entwicklungszeit und Installationszeit herleiten. Ich finde, ein entsprechend erweiterter Tanges Hyperbolicus trifft es ziemlich gut:
Installationszeit = 1/(60*24) * (1-tanh(Entwicklungszeit-Nötige Einarbeitungszeit)/2)

1/(60*24) ist der Faktor der nötig ist, wenn man davon ausgeht, dass die Installationszeit ca. 1 Minute mit dlls beträgt. Das ist schon recht sportlich ausgelegt.

Damit ergeben sich die Gesamtkosten zu:
1/(60*24)*N*W_ts/X*(1-tanh(TE-TEI)/2)+W_ts*TE.

Davon wollen wir ein Minimum finden, also Ableitung bilden. Usw.

Sagen wir, nun, dass wir zu gegebenen Parametern ein X finden wollen, sodass die Kostenfunktion ein globales Minimum an TE != 0 besitzt, also wenn man Zeit investiert hat um die dlls zu vermeiden. Sagen wir, die zusätzliche Einarbeitungszeit in MFC beträgt 14 Tage, sodass man keine dlls braucht. Sagen wir, dir ist Dein Tag 100€ wert. Sagen wir, Du hast 5 wirklich enge Freunde (mehr als das ist einfach keine wahre Freundschaft).

Daraus ergibt sich dann ein X von ca. 0.0001, sodass es sich unter globalen Aspekten lohnt, mit MFC zu arbeiten um keine dlls benutzen zu müssen. Anders ausgedrückt: Wenn für Dich die Zeit Deiner Freunde ca. 10000 Mal soviel Wert ist wie Deine eigene, dann solltest Du statisch gelinkt MFC benutzen (dafür entstehen aber auch weitere Kosten, weil nur die Pro+-Version von VS das unterstützt).
Entsprechend kannst Du das Modell natürlich für Deine eigene Situation anpassen.

CHR-Berger

[quote="Martin Richter"]

Ich mag die MFC eigentlich noch immer. Vielleicht auch deswegen, weil ich mich an Ihre Defizite gewöhnt habe.

Es gibt aber auch wenig Alternativen. Wie entwickelt man ansprechende GUI's ohne Framework. Gut es gibt Qt und noch ein paar andere nicht so verbreitete Frameworks. Wenn man den Spruch "veraltet" weg lässt und ein ansprechendes Ergebnis braucht, ist doch die MFC das Optimale. Viele Kunden von mir hanen noch alte Labtops min WIN3x oder WIN2000/XP. Wenn dann erst das DO.NET installiert werden muss, kommt es häufig zu Abstürzen oder der Kunde ist überfordert. Ich kann überhaupt nicht das AUS von MFC und anhaltende Kritik verstehen.
Du schreibst, dass du die MFC eigentlich immer noch magst, was magst du jetzt so richtig?

Martin Richter

Ei wie, jetzt muss ich ja lesen was ich geschrieben habe...

1. Für die MFC gibt es kein AUS! Jedenfalls habe ich davon nicht gehört und eigentlich habe ich einen guten Draht in die Produktgruppe.
2. Ich mag nicht eines der viel zitierten Frameworks wie QT etc. Ich bin froh nicht zu viel "neues" in der UI Entwicklung machen zu müssen. Die ATL mag ich sehr, aber nicht den Teil für die UI Entwicklung.
3. Ich muss nichts lieben um damit zu arbeiten. Ich bin Pragmatiker.
4. Also versuche ich die Werkzeuge zur Lösung der mir gestellten Probleme zu wählen, die aus allen Faktoren wie Wartbarkeit, Entwicklungszeit (vorhandener Code), Lernbedarf (vorhandenes Wissen), Effektivität ein entsprechendes Minimum bzw. Maximum liefern.
Letzten Endes verdiene ich mein Geld weil ich in diesem Sinne "gut" bin, oder sagen wir "mein Geld wert" zu sein.
Und diese Faktoren haben auch etwas mit der Aufstellung des Teams und der eigenen Fähigkeiten zu tun (Kernkompetenzen).
Mit unterschiedlichen Kompetenzen treffen wir unterschiedliche Entscheidungen.

Dieses Genöhle um Design/modern/etc. geht mir auch oft genug auf den Kecks.
Als Newbie würde ich anders entscheiden, als mit MFC/ATL/WinAPI Erfahrung seit dem wir Windows 3.0 haben. Aber ich bin kein Newbie. Und es fällt mir entsprechend schwer manche Libraries aus der Sicht von Newbies zu sehen...

Das ist auch der Grund warum ich mich mittlerweile vollkommen aus diesen Diskussionen raus halte. Inkl. Frage nach guten Tutorials etc.
Die fetten Clients, die ich betreue benutzen alle "erfolgreich" die MFC. Sie haben alle Look&Feel von Visual-Studio 2010.