4. Fenster Fehler

Fenster Fehler

  • Y

    Hallo,
    folgendes Fenster will sich nicht öffnen, sondern nur meine Error MessageBox "Create Window failed" 😕 Hier mein Code:

    #include <Windows.h>
#include <iostream>

LRESULT CALLBACK WndProc( HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam );
const	char szClassName[] = "AnnAProject";
		char szTitle[] = "Titel";

WNDCLASSEX WndClassEx;
HWND hWnd;
MSG msg;
UINT umsg;
WPARAM wParam;
LPARAM lParam;

int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR szCmdLine, int iCmdShow ){

WndClassEx.cbSize				= sizeof( WndClassEx );
WndClassEx.style				= NULL; 
WndClassEx.lpfnWndProc			= WndProc ;
WndClassEx.cbClsExtra			= NULL; 
WndClassEx.cbWndExtra			= NULL;
WndClassEx.hInstance			= hInstance; 
WndClassEx.hIcon			= NULL;
WndClassEx.hCursor			= NULL;
WndClassEx.hbrBackground		= ( HBRUSH ) (COLOR_WINDOW +1); 
WndClassEx.lpszMenuName			= NULL;
WndClassEx.lpszClassName		= szClassName;
WndClassEx.hIconSm			= NULL;

if( !RegisterClassEx( &WndClassEx )){
	MessageBox(NULL, "Register Class failed", "ERROR", MB_OK );
	return false;
}

hWnd = CreateWindowEx(	WS_EX_ACCEPTFILES, 
						szClassName, 
						szTitle, 
						WS_OVERLAPPEDWINDOW, 
						CW_USEDEFAULT, 
						CW_USEDEFAULT, 
						CW_USEDEFAULT, 
						CW_USEDEFAULT, 
						NULL, 
						NULL, 
						hInstance, 
						NULL );

if( hWnd == NULL ){
	MessageBox( hWnd, "Create Window failed", "ERROR", MB_OK );
	return false;
};
ShowWindow( hWnd, iCmdShow );

while( GetMessage( &msg, hWnd, NULL, NULL ) > NULL ){
	TranslateMessage( &msg );
	DispatchMessage( &msg );
};
return 0;
};
LRESULT CALLBACK WndProc( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam ){
	switch(msg){
		case WM_QUIT:
	{
		MessageBox(NULL, "Programm Ende", "Fertig", MB_OK );
		DestroyWindow( hWnd );
	};
			break;
		case WM_DESTROY:
			PostQuitMessage(0);
			break;
		default:
			return DefWindowProc( hWnd, msg, wParam, lParam );
};

}

    Irgend eine Idee wo der Fehler sein könnte? Der Kompiler sagt mir mehrmals bei i.welchen .dll Datein: Cannot find or open the PDB file

    0
  • N

    Lass mich raten: FlameDev?
    So gut der auch erklären mag, sein Stil ist eine Katastrophe.
    Globale Variablen, Halbwissen, ...
    Versuche mal das acceptfiles durch NULL zu ersetzen.

    0
  • Y

    Ich finde nicht mal dass er das gut erklären kann. Nur weil ich das angefangen habe muss ich jetzt damit auch durch, hab mir n Buch bestellt, in der Hoffnung, dass es mir C++ ordentlich beibringt 😉 ok, ich probiers aus und melde mich dann noch mal, wird aber erst früh morgens was weil ich jetzt los muss 😉

    0
  • N

    Welches Buch denn?
    Auch da gibt es schlimme.
    Finger weg von Büchern von Jürgen Wolf und ähnliche, schaue dazu hier: http://www.c-plusplus.net/forum/310212

    0
  • Y

    habs doch noch schnell probiert, hat aber nicht geholfen, gleiches Problem 😕 was ist eigentlich an seinem Stil so schlecht, dann kann ich es besser lernen? 🙂

    0
  • Y

    weil ich noch nen Gutschein hatte habe ich mir "Der C++ Programmierer" von Ulrich Breymann bestellt. Hat gute Bewertungen bekommen, und schien ziemlich umfangreich.

    0
  • M

    Nathan schrieb:

    Lass mich raten: FlameDev?
    So gut der auch erklären mag, sein Stil ist eine Katastrophe.
    Globale Variablen, Halbwissen, ...
    Versuche mal das acceptfiles durch NULL zu ersetzen.

    Genau so scheint es zu sein. Der Fehler liegt hier in bei einer globalen Variable.

    So würde es laufen; kleiner aber feiner Unterschied ... 🙂

    LRESULT CALLBACK WndProc( HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam )
{ 
    switch(msg){ 
        case WM_QUIT: { 
            MessageBox(NULL, TEXT("Programm Ende"), TEXT("Fertig"), MB_OK ); 
            DestroyWindow( hWnd ); 
            }; 
            break; 
        case WM_DESTROY: 
            PostQuitMessage(0); 
            break; 
        default: 
            return DefWindowProc( hWnd, msg, wParam, lParam ); 
    }
    return 0;
}

    PS: Habe char zu TCHAR umdefiniert wg. UNICODE.

    TCHAR szTitle[] = TEXT("Titel"); 
TCHAR szWindowClass[] = TEXT("AnnAProject");
    0
  • N

    Das Buch ist in Ordnung, ich gehe mal davon aus, dass dir dort auch guter C++Stil beigebracht wird, weil es hier im Forum empfohlen wurde.
    Das, was FlameDev da geschrieben hat, ist eigentlich kein C++, sondern C.
    In C++ verwendet man keine/kaum globale Variablen, hantiert nicht mit char-Arrays als String herum und packt solche Sachen wie Fenster-Erstellung in Klassen.
    OK, ich muss zugeben, bei der WinApi ist das ein bisschen schwierig, weil die eben in C geschrieben wurde...
    Jedenfalls, arbeite das Buch durch, und nutze so Sachen wie RAII, generischer Programmierung und andere C++-Techniken auch in eigenen C++-Programmen.

    0
  • Y

    Alles klar, da kann ich ja mit gutem Gewissen an das Buch gehen 😉 Ziemlich praktisch ist dabei dass die einem auch das kostenlose E-Book zur Verfügung stellen. Und danke für die Tips. Das Fenster öffnet sich jetzt einwandfrei! Danke dafür, Problem gelöst 🙂 👍

    0
  • P

    Nathan schrieb:

    In C++ verwendet man keine/kaum globale Variablen, hantiert nicht mit char-Arrays als String herum und packt solche Sachen wie Fenster-Erstellung in Klassen.
    OK, ich muss zugeben, bei der WinApi ist das ein bisschen schwierig, weil die eben in C geschrieben wurde...

    Hi und pardon 🙂

    Es gibt KEINEN einzigen Fall in welchem globale Variablen in C NÖTIG wären,
    tatsächlich bedeutet guter Programmierstil auch in C auf solchen Humbug zu verzichten.

    In der Winapi befindet man sich ja bereits in einem OOP Konstrukt
    und in eben diesem Konstrukt bedarf es keiner globalen Reichweite.

    Der einzige Einsatz der mir einfällt wären Demo s,
    allerdings sieht man ja wohin das führt..

    Durch C++ wurden Portabilität und Kapselung nicht erfunden,
    tatsächlich ist C++ ein Produkt konsequenter Regeleinhaltung in C.

    Hoffe das wird nicht als Flame verstanden.

    Viel Spass 🙂

    PS:
    Ich finde es sehr positiv das heute "Unicode" in aller Munde ist,
    aber wenn ich mir dann angucke wie zb. http-Requests anfällig dadurch werden
    das die Leute ihre Reinterpret-Casts/Cstrings nicht verstehen
    würde ich mir doch wünschen die C++ Programmierer
    hätten etwas mehr Zeit mit ihrer Pointer-/CharArray Lektion verbracht,
    schliesslich ist jeder C++ Programmierer auch ein C-Programmierer..

    0
  • -

    pVoid schrieb:

    PS:
    Ich finde es sehr positiv das heute "Unicode" in aller Munde ist,
    aber wenn ich mir dann angucke wie zb. http-Requests anfällig dadurch werden
    das die Leute ihre Reinterpret-Casts/Cstrings nicht verstehen
    würde ich mir doch wünschen die C++ Programmierer
    hätten etwas mehr Zeit mit ihrer Pointer-/CharArray Lektion verbracht,
    schliesslich ist jeder C++ Programmierer auch ein C-Programmierer..

    😃 👍

    0
  • M

    pVoid schrieb:

    In der Winapi befindet man sich ja bereits in einem OOP Konstrukt
    und in eben diesem Konstrukt bedarf es keiner globalen Reichweite.

    Wie bitte ?

    Die Funktionen der WinAPI sind ausschließlich in den Programmiersprachen C und Assembler geschrieben.

    http://de.wikipedia.org/wiki/Winapi

    Wenn man mit systemweiten Resourcen wie z.B. Semaphoren arbeitet macht es oft keinen
    Sinn die Handles lokal zu halten (obwohl das nicht unmöglich wäre).

    pVoid schrieb:

    PS: Ich finde es sehr positiv das heute "Unicode" in aller Munde ist, aber ...

    Das einige nicht wissen was unten drunter passiert rechtfertigt kein aber 😉

    0
  • P

    merano schrieb:

    Die Funktionen der WinAPI sind ausschließlich in den Programmiersprachen C und Assembler geschrieben.
    http://de.wikipedia.org/wiki/Winapi

    Nur weil etwas in C geschrieben ist kann es trotzdem OOP Paradigmen umsetzen (wie eben Windows).

    Das mit den lokalen Semaphoren ist misverständlich geschrieben.

    Creates or opens a named or unnamed semaphore object
    http://msdn.microsoft.com/en-us/library/windows/desktop/ms682438%28v=vs.85%29.aspx

    Es geht hier schon um (durch windows) verwaltete Objekte
    nicht wie bei globalen Variablen in C um selbst definierte Variablen
    welche der Programmierer selber verwalten muss.

    Es gibt viele Nachteile solche globaler Variablen in C aber nicht einen mir bekannten Vorteil.

    Mal ein Beispiel der Nachteile sichtbar macht welche nicht auf den ersten Blick erkenntlich sein müssen:

    1. Overhead - Angenommen Du erzeugst dynamisch Objekte welche der Compiler nicht optimiren kann, dann schleppst Du den Ballast im ganzen Programm mit Dir im Speicher rum.

    2. Wartbarkeit - Angenommen Deine Methode funktioniert so prima und Du willst ein Modul draus machen das Wiederverwendbar sein soll.
    Nun fängst Du an die Globale in einen Header zu stampfen und zwecks besserer Lesbarkeit bekommt die Variable je nachdem wo Du sie verwendest ein Alias.
    Irgendwann gefällt Dir der Name nicht mehr und Du benutzt die Replace Funktion Deiner IDE um deine Globale umzubenennen..
    ..und nun ergeben die wunderschön ungarisch notierten Funktionen keinen Sinn mehr
    ..und die Alias es zeigen ins Leere.

    Das alles kann man sich sparen wenn man "sauber" progammiert.

    Bei Unicode ist es so ähnlich.

    C / C++ / .. beliebig ergänzbar, "sprechen" nunmal nur Ansi.

    Wenn man jetzt wieder die replace Funktion in der IDE benutzt
    und aus jedem char ein tchar macht
    gibt es auch hier sehr viele Bereiche in denen Funktionen funkionsunfähig werden (wie eben der angedeutete http-Request).

    Sind wirklich 2 umfangreiche Themen und bin gerne bereit weiterzudiskutieren 🙂

    0
Anmelden zum Antworten