Ich hab gestern angefangen eine Klasse zu basteln, die als Grundlage für meine OpenGL Projekte dienen soll...
Da für MFC für Spiele ja nicht so unbedingt geeignet ist weil es doch recht hohe Geschwindigkeitseinbußen gibt hab ich das in der WinAPI geschrieben, genau hier hab ich jetzt ein kleines Problem :)

Das Ganze funktioniert jetzt insofern schon ganz gut das man eben ein Fenster erstellen kann, Auflösung ändern kann, Farbtiefe ändern kann und das ganze Standardzeug das so eine Klasse eben können sollte...

Bis jetzt muss man aber noch selbst die WinMain Funktion definieren, und in dieser dann eben die Instanz der Klasse deklarieren, und das Fenster mit der erstellen und anzeigen.. Natürlich wäre es schöner wenn ich die WinMain wie bei der MFC irgendwo fix unterbringen könnte...

Nur wo genau ist die WinMain bei der MFC ?
Und die WinMain ist ja der Einsprungspunkt des Windows Programmes, oder?
Also wie sage ich dann in der WinMain an welcher stelle der Quellcode weiter abgearbeitet werden soll?? (Das ist dann in einer anderen Quellcode Datei wo ich einfach eine Instanz von CGLWindow Erstelle und das Fenster anzeigen lasse, und wo ich die RenderGL() Methode, wie immer ich sie brauche, überlade)...

Tja. Also weiß jemand wie das in der MFC gelöst ist??

[url="http://www.thelordoftherings.com/cgi-bin/get-image.pl?ID=alan-lee-058 "]-N/A-[/url]
[url="http://www.microsoft.com/germany/ms/unternehmensinformationen/historie.htm "]Mean cats eat parakeets![/url]

Die WinMain() ist tief im Arsch von der MFC verkapselt =) Einsprungpunkt vom OS in das Programm sind zwei abgeleitete Klassen: Eine Klasse von CFrame, die andere von CDialog oder CEdit oder CWasweißich. Die Einsprungpunkte erledigt der Konstruktor aller Konstruktoren der MFC: CObject();
CObject() ist der tiefste Punkt im Arsch der MFC (sorry, aber der Ausdruck hat was =)

Kauf dir mal Jeff Prosise - Windowsprogrammierung mit der MFC 2. Auflage von Microsoft Press. Da steht alles drin, was man so für's MFC-Basteln wissen muß.

Btw: Ich selber habe damals im Stupidum (*ggg*) unter der MFC mit OpenGL programmiert. Datt geht eigentlich ganz easy von der Hand. Brauchst nur die Bibliotheken opengl32.lib, glu32.lib und glaux.lib.

Cu

PS: Ansonsten weiter fleißig mit der WIn32-API proggen =)

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

Das ganze ist eh in der WinAPI geschrieben, nur möchte ich eine art "mini mfc für opengl" basteln, weil die MFC selbst soviel ich weiß einen ganzen Haufen virtuelle Funktionen hat und nicht grad so toll für die Performance sein soll...

Aber bei der MFC reicht es ja eigentlich aus eine Klasse von CWinApp und eine von CFrameWnd abzuleiten und ein paar virtuelle methoden zu überschreiben um ein Fenster angezeigt zu bekommen...
Nur woher weiß die MFC wo diese Deklarationen/Definitionen stehen?? Wenn da s Programm irgendwo "tief im Arsch der MFC" :) anfängt kann es doch gar keine Ahnung von meiner Datei haben an der Ich in den Ablauf einsteige und eben ein paar Objekte erstelle...
Ich denk mal in der WinMain() Funktion wird da irgendwo auf meine Datei umgeleitet oder so oder? Aber wie um alles in der Welt kann das gehen? Mit einem Makro vielleicht? glaub ich eigentlich nicht.... hmm

hmm wie machen die das? weisst du das zufällig ? :)

[url="http://www.thelordoftherings.com/cgi-bin/get-image.pl?ID=alan-lee-058 "]-N/A-[/url]
[url="http://www.microsoft.com/germany/ms/unternehmensinformationen/historie.htm "]Mean cats eat parakeets![/url]

Sorry, war CFrameWnd =)

Wie ich bereits sagte, die WinMain() ist in CFrameWnd verkapselt worden und wird automatisch durch die Ableitung aufgerufen, die du aus CFrameWnd zwangsläufig erstellen mußt. Wo genau die WinMain() drinsteckt in welchen Dateien weiß ich auch net. Da hilft eventuell ein Blick in Headerdateien wie AFXWIN.H oder so.

Wenn Du eine OpenGL-basierte Mini-MFC erstellen willst, rate ich dir eigentlich nur dazu, alle bekannten (und benötigten) Dateien aus der Win32 API und OpenGL in eigene Klassen zu verkapseln. Aber wieso willst du dir soviel Mühe machen? Na egal...

Das virtuelle Funktionen etwas das System belasten, ist klar, schließlich handelt es sich bei solchen Ablegern um Funktionen, die late binding durchführen, also dynamisch zur Laufzeit vom Programm ihren Objekten zugeordnet werden. Aber die MFC geht ohne virtual eben nicht, weil das der einzigste Weg ist, das Polymorphismus-Dilemma aus dem Weg zu gehen. Beispielsweise JAVA ist permanent ans late binding gezwungen, was zusätzlich zum Interpretieren die ganze Sache geschwindigkeitsmäßig nicht zum Vorteil gereicht... Und ich glaube nicht, daß ein größeres Klassenkonzept wie du es vorhast OHNE late binding auskommt (außer du willst eine Hierarchie aus Klassen, die nichts voneinander bei der Vererbung überladen, hehehe. Da aber jeder Destruktor aus der Vaterklasse mindestens virtuell sein muß, hat sich deine Vorstellung vom virtual-freien Klassensystem schon erledigt).

Cu

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

danke für die antwort :) ich werd mir mal die afxwin.h genauer anschaun :)

das mit den virtuellen funktionen ist mir schon klar... genau deswegen will ich ja eine eigene kapselklasse schreiben die nur das wichtigste beinhaltet...

warum will ich mir so viel mühe machen? tja. kA :) programmieren rox und ich denke es ist die mühe wert :)

[url="http://www.thelordoftherings.com/cgi-bin/get-image.pl?ID=alan-lee-058 "]-N/A-[/url]
[url="http://www.microsoft.com/germany/ms/unternehmensinformationen/historie.htm "]Mean cats eat parakeets![/url]