First Windows Application Error

I'm having problems compiling the code that was given in the OpenGl/windows tutorial section.

Here is my code:

Code:

#define WIN32_LEAN_AND_MEAN #pragma comment(linker, "/subsystem:windows") #include <windows.h> LRESULT CALLBACK WndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam) { PAINTSTRUCT paintStruct; HDC hDC; char string[] = "Hello, World!"; switch(message) { case WM_CREATE: return 0; break; case WM_CLOSE: PostQuitMessage(0); return 0; break; case WM_PAINT: hDC = BeginPaint(hwnd,&paintStruct); SetTextColor(hDC, COLORREF(0x00FF0000)); TextOut(hDC,150,150,string,sizeof(string)-1); EndPaint(hwnd, &paintStruct); return 0; break; default: break; } return (DefWindowProc(hwnd,message,wParam,lParam)); } int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { WNDCLASSEX windowClass; HWND hwnd; MSG msg; bool done; windowClass.cbSize = sizeof(WNDCLASSEX); windowClass.style = CS_HREDRAW | CS_VREDRAW; windowClass.lpfnWndProc = WndProc; windowClass.cbClsExtra = 0; windowClass.cbWndExtra = 0; windowClass.hInstance = hInstance; windowClass.hIcon = LoadIcon(NULL, IDI_APPLICATION); windowClass.hCursor = LoadCursor(NULL, IDC_ARROW); windowClass.hbrBackground = (HBRUSH)GetStockObject(WHITE_BRUSH); windowClass.lpszMenuName = NULL; windowClass.lpszClassName = "MyClass"; windowClass.hIconSm = LoadIcon(NULL, IDI_WINLOGO); if (!RegisterClassEx(&windowClass)) { return 0; } hwnd = CreateWindowEx(NULL, "MyClass", "A Real Win App", WS_OVERLAPPEDWINDOW | WS_VISIBLE | WS_SYSMENU, 100,100, 400,400, NULL, NULL, hInstance, NULL); if (!hwnd) return 0; done = false; while(!done) { PeekMessage(&msg,hwnd,NULL,NULL,PM_REMOVE); if (msg.message == WM_QUIT) { done = true; } else { TranslateMessage(&msg); DispatchMessage(&msg); } } return msg.wParam; }

The error comes in this specific section with the last "NULL);"

Code:

hwnd = CreateWindowEx(NULL, "MyClass", "A Real Win App", WS_OVERLAPPEDWINDOW | WS_VISIBLE | WS_SYSMENU, 100,100, 400,400, NULL, NULL, hInstance, NULL);

Is there something wrong with my compiler or my code? Any help would be much appreciated as I am relatively new to all this and I'm trying to see exactly how the program runs and all works (and that's becoming difficult sense it won't work!)

>>Is there something wrong with my compiler or my code?<<

No idea about the compiler because you never said which one(s) you are using. ;)

NULL is for pointer types, the first parameter of CreateWindowEx requires a numeric type (DWORD) - set it to zero. Same goes for PeekMessage, too - those parameters set to NULL in your example code are also numeric types and should be set to zero instead.

You might consider just changing every case of NULL you come across to zero, unless you prefer to make a statement to yourself about the type(s) referred to.

I'd also suggest you remove the #pragma comment(linker, "/subsystem:windows") line as its ms specific and superfluous if you're building a windows application with their compilers anyway(it should be defined automatically for you, if you use a ms compiler). You might also consider losing '#define WIN32_LEAN_AND_MEAN', too, unless you have a slow system; all it does is eliminate a lot of headers for inclusion, which will require you to either drop the macro definition or manually add in those same, excluded headers at a later date when your programs become more complex, while it is defined.

Welcome to cboards. :)

In most cases NULL is a #define for 0, in the windows header, for sure, NULL is a #define for 0, so it makes no difference to the compiler if you use 0 or NULL.

Edit: The code you posted compiles just fine in VS2005...Only thing I had to do was turn off unicode in the compiler settings.

Quote:

You might also consider losing '#define WIN32_LEAN_AND_MEAN', too, unless you have a slow system;

I disagree. Defining WIN32_LEAN_AND_MEAN keeps a lot of junk out of your executable which you aren't using. For instance, windows.h by default includes winsock.h. Even if you are using sockets, you will want to include winsock2.h instead of winsock.h.

Look at the windows header:

Code:

#ifndef WIN32_LEAN_AND_MEAN #include <cderr.h> #include <dde.h> #include <ddeml.h> #include <dlgs.h> #ifndef _MAC #include <lzexpand.h> #include <mmsystem.h> #include <nb30.h> #include <rpc.h> #endif #include <shellapi.h> #ifndef _MAC #include <winperf.h> #include <winsock.h> #endif #ifndef NOCRYPT #include <wincrypt.h> #include <winefs.h> #include <winscard.h> #endif

How many of those headers do you use on a regular basis?

Quote:

In most cases NULL is a #define for 0, in the windows header, for sure, NULL is a #define for 0, so it makes no difference to the compiler if you use 0 or NULL.

Actually NULL is usually defined as ((void*)0), and it should only be used as a value for pointers. Interchanging 0 and NULL is a bad coding practice.

Quote:

Originally Posted by bithub

I disagree. Defining WIN32_LEAN_AND_MEAN keeps a lot of junk out of your executable which you aren't using. For instance, windows.h by default includes winsock.h. Even if you are using sockets, you will want to include winsock2.h instead of winsock.h.

Look at the windows header...How many of those headers do you use on a regular basis?

You make some very good points and I respectfully withdraw my earlier suggestion regarding this macro definition. :)

Quote:

Originally Posted by bithub

Actually NULL is usually defined as ((void*)0), and it should only be used as a value for pointers. Interchanging 0 and NULL is a bad coding practice.

That depends on whether this is C or C++ (well, actually I'm not sure about C). I remember being told that NULL is defined in the C++ standard as 0. Still, interchanging 0 and NULL isn't good (it could lead to confusion, at least).

That's true, in C++ NULL is defined as 0 in most (if not all) cases.

Quote:

Originally Posted by bithub

Actually NULL is usually defined as ((void*)0), and it should only be used as a value for pointers. Interchanging 0 and NULL is a bad coding practice.

I respectfully diagree... with the help of Bjarne Stroustrup

Quote:

Should I use NULL or 0?
In C++, the definition of NULL is 0, so there is only an aesthetic difference. I prefer to avoid macros, so I use 0. Another problem with NULL is that people sometimes mistakenly believe that it is different from 0 and/or not an integer. In pre-standard code, NULL was/is sometimes defined to something unsuitable and therefore had/has to be avoided. That's less common these days.

Personally I always use 0 also.. but still I realize they "should" be the same.

Quote:

I respectfully diagree... with the help of Bjarne Stroustrup

In C++ NULL and 0 are the same. This is not true with C.

From my stdlib.h file:

Code:

/* Define NULL pointer value */ #ifndef NULL #ifdef __cplusplus #define NULL 0 #else #define NULL ((void *)0) #endif #endif

I've worked on plenty of compilers where the following would fail:

Code:

if(NULL == 0)

Okay half-fixed

Okay I set all the NULL to 0 and I'm no longer getting an error with those. However now I am getting linker errors with settextcolor, textout, and getstockobject.

Any ideas here?

Edit: BTW I'm using Dev-C++ for a compiler atm.

Bithub, I'll accept that for C, nonetheless, in this instance, windows.h definitely defines it as 0

Grimmy, are you linking in the gdi library? ( atm I don't use devC, but I am guessing it's gdilib.a)

Quote:

Bithub, I'll accept that for C, nonetheless, in this instance, windows.h definitely defines it as 0

How can you say that? First of all, NULL is not defined in windows.h, it is defined in windef.h as follows:

Code:

#ifndef NULL #ifdef __cplusplus #define NULL 0 #else #define NULL ((void *)0) #endif #endif

well..I looked and I stand corrected, I guess I've never noticed because I always use c++ which in those instances it is always 0.

Quote:

Originally Posted by Grimmy

Okay I set all the NULL to 0 and I'm no longer getting an error with those. However now I am getting linker errors with settextcolor, textout, and getstockobject.

Any ideas here?

Edit: BTW I'm using Dev-C++ for a compiler atm.

Go into the 'project options' dialog from the project menu, select the 'general' tab (the dialog should actually open with this active by default) and select 'Win32GUI' from the 'type' list. This should ensure that the proper windows libs are linked. If this doesn't work then you may need to manually state the libraries you wish to link, usually with the -mwindows linker switch - but try my first suggestion and see if that works.

For future reference, if you choose an 'Empty Project' from the 'new project' dialog when you initially create your project and want that project to be a windows application, then set the 'Win32GUI' option as I have described above.

Woohoo

Okay I got it to work! Thanks a ton for all the input - I'll let ya'll know if I have any other problems.

Thanks again all.