-
January 25th, 2013, 11:05 PM
#1
[RESOLVED] starter app not responding
The following code results in simple window which stops responding as soon as it is executed.
i really have no idea what is happening, i am just starting visual c++
#include<windows.h>
#include<stdio.h>
#ifndef UNICODE
#define UNICODE
#endif
LRESULT CALLBACK windowprocess (HWND hwindow, UINT uMsg, WPARAM wParam, LPARAM lParm);
int WINAPI wWinMain (HINSTANCE hInstance, HINSTANCE, PWSTR pCmdLine, int nCmdShow)
{
WNDCLASSEX wc ={};
wc.lpfnWndProc = windowprocess;
static LPCSTR CLASS_NAME = "Starter Window Class";
wc.lpszClassName = CLASS_NAME;
wc.hInstance = hInstance;
wc.cbSize = sizeof(WNDCLASSEX);
RegisterClassEx (&wc) ;
HWND hWnd;
hWnd = CreateWindowEx ( 0, // Optional window styles.
CLASS_NAME, // Window class
"Starter App", // Window text
WS_OVERLAPPEDWINDOW, // Window style
// Size and position
CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,
NULL, // Parent window
NULL, // Menu
hInstance, // Instance handle
NULL // Additional application data
);
// printf("Window created");
if(!hWnd)
{return 0;}
// printf("window verified");
ShowWindow(hWnd, nCmdShow);
LPMSG Msg;
while(GetMessage(Msg, hWnd, 0, 0))
{
TranslateMessage(Msg);
DispatchMessage(Msg);
}
return 0;
}
LRESULT CALLBACK windowprocess (HWND hwindow, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch(uMsg)
{
case WM_DESTROY:
PostQuitMessage(0);
return 0;
break;
case WM_PAINT:
{
PAINTSTRUCT ps;
HDC hdc = BeginPaint(hwindow, &ps);
FillRect(hdc, &ps.rcPaint, (HBRUSH) (COLOR_WINDOW+1));
EndPaint(hwindow, &ps);
}
break;
default:
return DefWindowProc(hwindow, uMsg, wParam, lParam);
}
}
-
January 26th, 2013, 01:36 AM
#2
Re: starter app not responding
Originally Posted by pavankn18
The following code results in simple window which stops responding as soon as it is executed.
i really have no idea what is happening, i am just starting visual c++
1) Please use code tags when posting code. The code you posted is almost unreadable.
2) You should take working examples before trying to code a Windows application yourself.
Code:
LRESULT CALLBACK windowprocess (HWND hwindow, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch(uMsg)
{
case WM_DESTROY:
PostQuitMessage(0);
return 0;
break;
case WM_PAINT:
{
PAINTSTRUCT ps;
HDC hdc = BeginPaint(hwindow, &ps);
FillRect(hdc, &ps.rcPaint, (HBRUSH) (COLOR_WINDOW+1));
EndPaint(hwindow, &ps);
}
break;
//??? So what does WM_PAINT return??
}
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx
Return value
An application returns zero if it processes this message.
You are returning an unknown value back to the OS.
In general, whenever you process a message, you must return what is documented that you return for the particular message. Don't guess, don't leave the return empty, etc. You are to return 0 if you process the WM_PAINT message.
3)
Code:
#ifndef UNICODE
#define UNICODE
#endif
Why are you doing this? The build settings already have these preprocessor constants defined for you.
Regards,
Paul McKenzie
Last edited by Paul McKenzie; January 26th, 2013 at 01:42 AM.
-
January 26th, 2013, 02:33 AM
#3
Re: starter app not responding
Thanks paul for your suggestions,
1. adding a return statement did not solve the problem.
2.comparing with example code in msdn, difference is i used LPMSG and did not use & when passing to translate and dispatch functions in message loop while example uses MSG type and use & in those functions as they need pointer.
if you look in the function definition both functions needs their argument to be LPMSG type, so why program crashes if i use LPMSG in message loop?
as beginner i would ignore it, but i fear i would keep accumulating such things which can make writing stable programs more difficult.
I will appreciate any help i can get.
-
January 26th, 2013, 05:03 AM
#4
Re: starter app not responding
Originally Posted by pavankn18
if you look in the function definition both functions needs their argument to be LPMSG type, so why program crashes if i use LPMSG in message loop?
as beginner i would ignore it, but i fear i would keep accumulating such things which can make writing stable programs more difficult.
Code:
LPMSG Msg; // you have garbage here in Msg pointer
while(GetMessage(Msg, hWnd, 0, 0)) // and here the garbage gets dereferenced inside GetMessage
{
TranslateMessage(Msg);
DispatchMessage(Msg);
}
No surprise it crashes on garbage pointer dereference. The correct code must look like this:
Code:
MSG Msg; // not a pointer, but structure !!!
while(0 < GetMessage(&Msg, NULL, 0, 0))
{
TranslateMessage(&Msg);
DispatchMessage(&Msg);
}
The two snippets differ drastically. In first case pointer variable being used actually points to no really allocated memory. Writing to unallocated memory results in crash in your case. I would say you're lucky to have this crashed, as the garbage pointer might accidentally point to an allocated memory, which is going to be just corrupted by the write operation.
Second snipped has a real MSG structure allocated on stack and allowed for writing. This way all write operations deal with valid memory region, and further reads will be done from this known memory.
The main lesson you should learn from this: making the code be just compilable without complying to real physical meaning of the construct is not enough to make your program run correctly. Code may compile successfully being at the same time physically senseless or even harmful.
Another lesson learned is: You cannot write program in C/C++ having no idea of how language constructs correspond to physical computer architecture.
Lesson to be learned later: You cannot write any relatively complex program for some OS having no idea of OS architecture and physical specifics of its implementation.
Last edited by Igor Vartanov; January 26th, 2013 at 05:32 AM.
Best regards,
Igor
-
January 26th, 2013, 06:07 AM
#5
Re: starter app not responding
Thank you sir i got it.
adding a line Msg = new MSG; do make the program stable, will try to be careful
feeling really nice now
Last edited by pavankn18; January 26th, 2013 at 06:13 AM.
-
January 26th, 2013, 06:56 AM
#6
Re: starter app not responding
Originally Posted by pavankn18
Thanks paul for your suggestions,
1. adding a return statement did not solve the problem.
But it corrected another problem, and that is the return of a garbage value back to the OS.
2.comparing with example code in msdn, difference is i used LPMSG and did not use & when passing to translate and dispatch functions in message loop while example uses MSG type and use & in those functions as they need pointer.
You made a mistake that a lot of beginner C/C++ programmers make, and that mistake is believing that if a function requires a pointer, you must declare a pointer and give it to the function.
When a function requires a pointer, that function is actually asking you to provide the address of an existing variable. That is how C and C++ prototype and document functions that require an address -- pointer parameters are used to denote this.
So you provided an uninitialized pointer to the function, and what do you think happens when you pass an uninitialized pointer to a function? First, there is no function in the world of C++ that can take a passed in uninitialized pointer and do anything with it that's safe. Second, since the function assumed that the pointer you passed actually points to a valid location, it goes and attempts to write to that location, so you get the crash.
The other extreme of this mistake is declaring a pointer, calling malloc() or "new" to allocate memory, and then passing that pointer. Even though this may work, it's dumb -- it slows the code down, possibly introduces a memory leak, and honestly, looks amateurish and unprofessional to a seasoned C/C++ programmer.
Regardless, whenever a function requires a pointer, it is asking for an address of something that exists. Passing uninitialized pointers, or declaring a pointer, needlessly allocating memory, and then passing that pointer are both mistakes in not understanding how C/C++ works with respect to prototyping functions.
Regards,
Paul McKenzie
Last edited by Paul McKenzie; January 26th, 2013 at 07:44 AM.
-
January 26th, 2013, 06:58 AM
#7
Re: starter app not responding
Originally Posted by pavankn18
Thank you sir i got it.
adding a line Msg = new MSG; do make the program stable, will try to be careful
feeling really nice now
No.
Read my post carefully. Why are you calling "new"? You have now made both mistakes that I mentioned. You are now calling the allocator for no reason whatsoever, and also you probably introduced a memory leak.
Regards,
Paul McKenzie
Last edited by Paul McKenzie; January 26th, 2013 at 07:00 AM.
-
January 26th, 2013, 07:31 AM
#8
Re: starter app not responding
Originally Posted by pavankn18
adding a line Msg = new MSG; do make the program stable, will try to be careful
feeling really nice now
Maybe you wouldn't after reading Paul's comments.
Try to see difference:
Code:
void foo(Type*);
void clever()
{
Type t; // created on stack
foo(&t); // passed by address operator
// automatically deallocates on leaving function scope
}
void dumb()
{
Type* pt = new Type; // created on heap
foo(pt); // passed by pointer value
// if not deleted, leaked on leaving function scope, never gets deleted later
}
void notSoClever()
{
Type* pt = new Type; // created on heap
foo(pt); // passed by pointer value
delete pt; // requires to be explicitly deallocated,
// and hardly has any advantage compared to stack variable
}
Variable must have some solid reason to be allocated on heap. Typically the reason is that variable lifespan must extend beyond function scope where it was created. Definitely not your case. Besides, explicit use of new requires for explicit delete, which makes such sort of allocation be prone to leaking.
Last edited by Igor Vartanov; January 26th, 2013 at 07:35 AM.
Best regards,
Igor
-
January 26th, 2013, 11:16 PM
#9
Re: starter app not responding
Thank you,
please help me with the following,
1.when i write a function with a return type and no return value it will result in compile time error, but why compiler did not complain
anything in windowsproc? compiler wont tell anything even in case of int main with no return statement.
2.what is the actual return type of windowsproc? LRESULT has definition #define LONG_PTR LRESULT, further #define _w64 LONG_PTR.
what is _w64? how shall i interpret it?
-
January 27th, 2013, 03:26 AM
#10
Re: starter app not responding
Originally Posted by pavankn18
1.when i write a function with a return type and no return value it will result in compile time error, but why compiler did not complain
anything in windowsproc?
That is because it did have a return statement. The problem with your window procedure is that it didn't have a definite return value for each exit point.
compiler wont tell anything even in case of int main with no return statement.
The main() is a special function in C++. If no return is specified, then the return value from main() is 0. That's the rule of C++.
2.what is the actual return type of windowsproc? LRESULT has definition #define LONG_PTR LRESULT, further #define _w64 LONG_PTR.
what is _w64? how shall i interpret it?
Why should you care? Just return an integral value, and there is nothing else to worry about.
Regards,
Paul McKenzie
-
January 27th, 2013, 04:54 AM
#11
Re: starter app not responding
Thank you
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|