4. MFC frei?

MFC frei?

  • E

    Danke für die Info! Ich finde, ein Umstieg bei den MFC Funktionen auf Unicode ist verkraftbar.

    https://www.visualstudio.com/vs-2015-product-editions
    Beim Download wird das MFC-MBCS-Paket angezeigt (man muss es nicht gesondert auswählen).

    0
  • ?

    Bisher habe ich immer alle Projekte versucht auf UNICODE umzustellen, aber ein Projekt macht mir Sorgen, es ist aber ein reines C/API-Projekt...meiner Meinung nach ist es ein Bug...bloß wo er liegt ist die Frage (bei mir oder dem Compiler) 😃

    0
  • E

    Die WinAPI-Funktionen nehmen immer noch gerne den klassischen ANSI-Code. 😉

    0
  • E

    Ein Problem habe ich mit der VS 2015 Community: Ich bin auf der Suche nach dem "ATL-COM-Anwendungs-Assistenten" zur Erstellung neuer ATL-Objekte als DLL, ausführbare Datei oder Dienst. Bisher habe ich das noch nicht gefunden, vielleicht bei der Installation vergessen. Wenn ja, kann man das im Nachhinein installieren? Kann jemand helfen?

    0
  • L

    Bei mir läuft die 2015 Community bloß als 30-Tage-Testversion. Wo bekomme ich den Key her um sie freizuschalten?

    0

  • Über "Help/About" auf den Link "License Status" klicken und dann mit einer MS Live-ID anmelden (bzw. registrieren).

    0
  • L

    Th69 schrieb:

    Über "Help/About" auf den Link "License Status" klicken und dann mit einer MS Live-ID anmelden (bzw. registrieren).

    Danke, aber anders geht's nicht?
    Wieder ein Konto mehr, das ich nur ein Mal brauche. 😞

    0
  • E

    Danke, aber anders geht's nicht?
    Wieder ein Konto mehr, das ich nur ein Mal brauche.

    Ja, alles hat seinen Preis. 🙄

    0
  • L

    Erhard Henkes schrieb:

    Danke, aber anders geht's nicht?
    Wieder ein Konto mehr, das ich nur ein Mal brauche.

    Ja, alles hat seinen Preis. 🙄

    Ja, total nervig. Alle wollen deine Daten. Warum auch immer. Dass ich überall Phantasie-Daten angebe, merken die nicht einmal.

    0
  • E

    @Leprechaun: "ATL-COM-Anwendungs-Assistent" <== kannst Du mir da weiter helfen? Ich würde gerne eigene ATL COM erstellen (siehe: http://henkessoft.de/C++/MFC/mfc_einsteigerbuch_kapitel15.htm).
    ... oder allgemein: wie erzeugt man heute diese COM DLLs?

    0
  • L

    Erhard Henkes schrieb:

    @Leprechaun: "ATL-COM-Anwendungs-Assistent" <== kannst Du mir da weiter helfen? Ich würde gerne eigene ATL COM erstellen (siehe: http://henkessoft.de/C++/MFC/mfc_einsteigerbuch_kapitel15.htm).
    ... oder allgemein: wie erzeugt man heute diese COM DLLs?

    Habs selbst nie gemacht, sieht aber nach ziemlich üblem Gefummel aus: https://support.microsoft.com/en-us/kb/181265

    Btw, meines bescheidenen Halbwissens nach, lässt MS die COM-Geschichte, die es einst so gehyped hat, langsam einschlafen, bzw. nutzt es nur noch für den hausinternen Gebrauch.

    0
  • E

    Ja, das Gefühl habe ich auch inzwischen, war so eine Art "Fortsetzung der DLL Hölle." 😃
    Die Frage ist, was tut man stattdessen, wenn man C++/MFC einsetzen will?

    Folgender Artikel brachte mich ein Stück weiter:
    http://www.codeproject.com/Articles/505791/Writing-Simple-COM-ATL-DLL-for-VS (Tipp von MrX)

    0
  • M

    Leprechaun schrieb:

    Btw, meines bescheidenen Halbwissens nach, lässt MS die COM-Geschichte, die es einst so gehyped hat, langsam einschlafen, bzw. nutzt es nur noch für den hausinternen Gebrauch.

    Nö, auch die neuesten APIs, wie WinRT, basieren auf COM.

    0
  • E

    Schön zu hören, dass COM noch lebendig ist.
    Mit dem Link oben habe ich es auch mit VS 2015 Community geschafft.

    1. Wichtig: VS 2015 als Admin öffnen (Rechtsklick auf das VS Icon im Startmenü: Als Admin ausführen!), damit regserv die DLL in der Registry anmelden kann.
    2. ATL Projekt anlegen und dort später eine Klasse hinzufügen (ATL, z.B. einfaches Objekt)
      Also alles vorhanden in VS Community 2015.

    Ich habe dies in meinem Kap. 15 in http://henkessoft.de/C++/MFC/MFC Tutorials.htm auf den neuesten Stand gebracht. Vielleicht hilft das auch anderen.

    0
  • A

    Mechanics schrieb:

    Nö, auch die neuesten APIs, wie WinRT, basieren auf COM.

    Im Kern ja, aber wohl auf einen überarbeiteten COM-Unterbau.

    0
  • E

    Die MFC sind - seit MSVC++6 - über viele Jahre stabil geblieben, wirklich bewundernswert.

    0
  • M

    Ich wüsste nicht, was an dem COM Kern überarbeitet worden sein soll. Ich hab nur gelesen, dass die jetzt wohl ein anderes Format für Interfacebeschreibungen benutzen, aber das ist für mich nur ein marginaler Nebenaspekt.

    Ich weiß nicht, ob ich das so bewundernswert finde, dass die MFC noch genauso schlecht ist wie vor 20 Jahren ^^. Die API ist schon sehr unangenehm.

    0
  • ?

    Mechanics schrieb:

    [...]

    Ich weiß nicht, ob ich das so bewundernswert finde, dass die MFC noch genauso schlecht ist wie vor 20 Jahren ^^. Die API ist schon sehr unangenehm.

    Ha ha, sehr witzig...was ist an den "neuen" Technologien so angenehm...wenn ich mir "C# und NET" ansehe, dann weiß ich nicht, was besser sein soll, außer die Gewohnheit. 😉

    0
  • M

    Ich rede eher von vergleichbaren C++ APIs, wie Qt 😉 Wobei Qt jetzt auch nicht unbedingt perfekt ist, aber egal. Allein diese ganzen Klassen, die verstecken sollten, dass der Compiler nicht richtig mit Templates umgehen kann, wie CMapStringToString. Es gibt keinen eingebauten Layout Manager, es gibt lauter hässliche Macros usw. usf. Mindestens um 20 Jahre veraltet.

    0
  • A

    ralros schrieb:

    Mechanics schrieb:

    [...]

    Ich weiß nicht, ob ich das so bewundernswert finde, dass die MFC noch genauso schlecht ist wie vor 20 Jahren ^^. Die API ist schon sehr unangenehm.

    Ha ha, sehr witzig...was ist an den "neuen" Technologien so angenehm...wenn ich mir "C# und NET" ansehe, dann weiß ich nicht, was besser sein soll, außer die Gewohnheit. 😉

    Mhh, was ist an C# und .Net angenehmer als an der MFC? Alles? Wenn es nach der Gewohnheit gehen würde, müsste ich weiterhin C++ bevorzugen, damit verdiene ich bis zum heutigen Tag mein Geld - doch ich halte C#/.Net für weitgehend besser (zumindest in größeren Businessanwendungen).

    1. Ich habe nirgens mit binaries zu tun, die sich auch mal zerschießen (gut, Erfahrung ist schon sehr alt - genauer von MFC 1.5 und 4.0).

    2. Ich kann Inhalt und Logik sehr gut voneinander trennen, richtig aufgezogen sogar soweit das ich bis auf die eigentliche Oberflächendefinition den Code zwischen Plattformen (Windows, WP, iOS und Android - teilweise sogar MacOS) austauschbar machen kann.

    3. Ich brauche weniger Code für den gleichen Aufwand, sofern ich nicht um andere Ziele zu verwirklichen (z.B. bessere Testbarkeit etc.) zusätzlichen Code bewusst in Kauf nehme.

    4. Die Werkzeugunterstützung ist unter C# einfach besser (Refactoring usw.).

    5. Sobald .Net 5 aus der Beta ist, kann ich sogar den Servercode unabhängig von Windows halten.

    6. Ach, und nicht zu vergessen: wesentlich bessere Layout und Skalierungseigenschaften der Oberfläche.

    0
Anmelden zum Antworten