Hallo ich arbeite mich gerade in MFC durch.
Ich bin aber noch im Anfang aller Dinge und habe ein Problem bei WndProc
unter Windows XP. Ich ahbe das Bespiel von Ihnen kopiert und erhalte
Fehlermeldungen bei dem Systemaufruf von WnProc bei der Kompilierung. In
der Onlinehilfe ist die Funktion aber bennant und auch richtig.
Können Sie mir einen Tipp geben?
// FirstWin.cpp : Definiert den Einsprungpunkt für die Anwendung.
//
#include "stdafx.h"
// Konstanten
// ----------
// Fensterklassen-Name
LPCTSTR lpszWCLASSNAME = "ERSTES FENSTER";
int APIENTRY WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow )
{
// ZU ERLEDIGEN: Fügen Sie hier den Code ein.
// Fensterklasse registrieren
// --------------------------
// WNDCLASS-Strukur
WNDCLASSEX WndClass;
// Struktur mit '0' vorbelegen
memset(&WndClass,0,sizeof(WndClass));
WndClass.cbSize = sizeof(WndClass);
// Fensterprozedur einhaengen
WndClass.lpfnWndProc = WndProc;
// Instanzen-Handle
WndClass.hInstance = hInstance;
// Icon fuer Fensterklasse laden
WndClass.hIcon = LoadIcon(0,IDI_WINLOGO);
// Cursor fuer Fensterklasse laden
WndClass.hCursor = LoadCursor(0,IDC_UPARROW);
// Fensterhintergrund setzen
WndClass.hbrBackground = (HBRUSH)GetStockObject(LTGRAY_BRUSH);
// Fensterklassen-Name
WndClass.lpszClassName = lpszWCLASSNAME;
// Fensterklasse registrieren
RegisterClassEx(&WndClass);
return 0;
}
Kompilierung läuft...
FirstWin.cpp
C:\VISUAL-C-WORK\FirstWin\FirstWin.cpp(23) : error C2065: 'WndProc' :
nichtdeklarierter Bezeichner
C:\VISUAL-C-WORK\FirstWin\FirstWin.cpp(23) : error C2440: '=' : 'int'
kann nicht in 'long (__stdcall *)(struct HWND__ *,unsigned int,unsigned
int,long)' konvertiert werden
Die Konvertierung eines ganzzahligen Typs in einen Zeigertyp
erfordert ein reinterpret_cast-Operator oder eine Typumwandlung im C-
oder Funktionsformat
Fehler beim Ausführen von cl.exe.
FirstWin.exe - 2 Fehler, 0 Warnung(en)
WndProc ist der traditionelle Name der Funktion, die an die Windows Message Loop angehängt wird und Messages bearbeitet. Und nein, diese Funktion müsstes du selber schreiben. Aber sag: Was um alles in der Welt machst du da? Es kommt zwar vor, das man mit der MFC an solche Internals ran muss, aber ganz sicher nicht am 'Anfang aller Dinge'. Das ist hardcore Windows C-API Programmierung und eigentlich sollte einen die MFC genau davor schützen, sich mit solchen Dingen rumschlagen zu müssen. (Das tut sie auch. Manchmal mehr schlecht als recht, aber sie tut es)
Ich habe im Internet ein Tutorial gefunden. Das ist eigentlich ganz gut gemacht. Aber Beim Compilieren stoße ich an diese Fehlermeldung. Bei diesem Tutorium geht es darum zu verstehen was MFC macht und wie Fenster behandelt werden. Hintergrund ist, dass man dann auch mal versteht was der Assistent da hinzaubert falls es mal klemmt. Und ein Beispiel wurde gemacht um zu zeigen wie man Fenster aufbaut. www.cpp-tutor.de
Ich sehe es wie Karl-Heinz: Für den Einstieg in die MFC ist das, was Du Dir da antust, absolut nicht zweckdienlich. Erst sehr viel später, wenn Du mal irgendwo an eine Grenze stösst, mag ein Eingriff unter der Motorhaube sinnvoll sein. Die MFC sind doch dazu da, den ganzen Windows-Unterbau zu kapseln. Was Du da machst, erinnert mich stark an mein erstes Buch zum SDK von Windows 2.11 von Charles Petzold. Nö nö.
Grundsätzlich finde ich es eine gute Idee, wenn man auch mal schaut was "hinter den Kulissen" passiert, aber für die ersten Schritte ist das sicherlich noch nicht angemessen. Die MFC ist relativ komplex und SW technisch gesehen nicht unbedingt das, was ich ein sauberes und übersichtliches Design nennen würde. Mit anderen Worten das Wissen um die MFC Internas fördern nicht das grundsätzliche Verständnis der MFC. In der MSDN findest Du reichlich Material zur MFC Verwendung (damit würde ich beginnen) und (für danach) Details über den Aufbau und die Internas. Warum verwendest Du überhaupt die MFC? Gibt es einen besonderen Grund dafür? Zur Erstellung einer Windows Applikation greife ich heute nur noch dann auf die MFC zurück, wenn es sich überhaupt nicht vermeiden läßt, d.h. es gibt zwingende Gründe dafür. Mittlerweile gibt es deutlich effizientere Möglichkeiten Windows Applikationen zu entwickeln: .NET (in C++ oder C#, ggf. VB) oder Swing / AWT (Java), "höhere" Skriptsprachen wie Python oder Ruby. Die Wahl der Umgebung hängt natürlich vom zu lösenden Problem ab.
Die von Dir erwähnten Alternativen sind allesamt nicht mit C++
programmierbar, auch das .Net-Geraffel nicht. Was sich da C++
schimpft, ist tatsächlich "managed C++", und das hat mit C++ nicht mehr
sonderlich viel gemein.
Es gibt hinreichend ausdiskutierte Gründe, keine zig MB große
Laufzeitumgebung zu verwenden, und die MFC als "echte"
C++-Klassenbibliothek erlaubt es, statisch gelinkte Anwendungen zu
produzieren, ohne Abhängigkeiten von der "DLL-Hölle" und ohne
Abhängigkeiten von irgendeiner CLR. Andere Programmiersprachen,
Skriptsprachen gar, sind in manchen Fällen erst recht keine Alternative.
Viel MFC-Bashing bezieht sich auf die zu Recht als veraltet zu
bezeichnende Version, die mit VC6 verwendet wurde -- die mit VC9
("Visual Studio 2008") verwendete MFC-Variante ist aber inhaltlich
massiv überarbeitet worden und setzt auch einige C++-Konstrukte ein, die
VC6 aufgrund des recht lausigen Compilers nicht unterstützte.
Alternativen zur MFC, die ebenfalls mit C++ programmiert werden können,
wären Qt und wxWidgets, beide bieten den Vorteil einer gewissen
Plattformunabhängigkeit (damit lassen sich auch Anwendungen für *nix und
Mac OS X erzeugen).
Für MFC-Erfahrene bietet wxWidgets den Vorteil einer gewissen
strukturellen Ähnlichkeit, d.h. manche Konzepte sind sich sehr ähnlich.
Im Gegensatz zur sehr auf eine ganz spezifische Vorgehensweise
ausgerichteten MFC bietet wxWidgets dann aber im Detail mehr
Freiheitsgrade.
Für Leute, die erst jetzt damit anfangen, ist ein solches
plattformübergreifend einzusetzendes Werkzeug sicherlich sinnvoller als
eine Bindung an Windows, die mit der MFC einhergeht.
<Pedanterie>
interna ist bereits ein Plural.
Ich benutzte die MFC eigentlich immer noch gerne. Dafür gibt es 2 Gründe: Zum einen, wie Rufus schon angesprochen hat, kann ich alles statisch linken. Ich seh einfach nicht ein, warum ich ein 40MB Framework auf einer Maschine haben soll, wenn ich das Ganze mit der MFC statisch gelinkt unter 1 MB haben kann. Ich hab hier viele derartige Exe von Programmen, die vor Jahren geschrieben wurden. CD raus ... EXE gestartet ... läuft. Keine Probleme mit Versionschaos oder sonstigen notwendigen Updates. Und im Vergleich zu dem .Net Geraffel startet das Exe in Windeseile. Zum anderen schätze ich die Document/View Architektur, die einem die MFC mehr oder weniger aufzwingt und die sehr gut funktioniert. Ich hab hier ein Qt Programm übernommen und ich wünschte der Autor hätte vorher ein paar Jahre lang mit der MFC den Document/View Gedanken verinnerlicht bzw. sich angesehen wie die Aufgabenverteilung bei Dialogen sinnvoll gemacht werden kann. Nachteilig bei der MFC ist für mich lediglich, dass man bei moderneren GUI Konstrukten im Regen steht, sofern man keine Fremdlibraries dafür hat bzw. sich im Fundus nichts passendes findet. Auch mit dem OCX/Active X Zeugs konnte ich mich über die Jahre hinweg dann doch noch anfreunden. Anfangs (~1996, 97) gabs damit eigentlich immer nur massiven Ärger. VOn 100 Kunden waren immer 2 oder 3 dabei, bei denen sich OCX-Controls nicht richtig registrieren liessen.
Rufus t. Firefly wrote: > Die von Dir erwähnten Alternativen sind allesamt nicht mit C++ > programmierbar, auch das .Net-Geraffel nicht. Was sich da C++ > schimpft, ist tatsächlich "managed C++", und das hat mit C++ nicht mehr > sonderlich viel gemein. > > Es gibt hinreichend ausdiskutierte Gründe, keine zig MB große > Laufzeitumgebung zu verwenden, und die MFC als "echte" > C++-Klassenbibliothek erlaubt es, statisch gelinkte Anwendungen zu > produzieren, ohne Abhängigkeiten von der "DLL-Hölle" und ohne > Abhängigkeiten von irgendeiner CLR. Andere Programmiersprachen, > Skriptsprachen gar, sind in manchen Fällen erst recht keine Alternative. > > Viel MFC-Bashing bezieht sich auf die zu Recht als veraltet zu > bezeichnende Version, die mit VC6 verwendet wurde -- die mit VC9 > ("Visual Studio 2008") verwendete MFC-Variante ist aber inhaltlich > massiv überarbeitet worden und setzt auch einige C++-Konstrukte ein, die > VC6 aufgrund des recht lausigen Compilers nicht unterstützte. > Wer jetzt hier Bashing betreibt sei mal dahin gestellt... Das Tools muss halt zum Problem passen, das war mein Punkt. Was Du da rein interpretierst sei Dir überlassen. > > <Pedanterie> > interna ist bereits ein Plural. Wenn es Dir hilft.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.