Well I've tried doing it as you told me, but strangely it keeps closing both main and seconday dialogs, here is how it's going:
Code://PRINCIPAL DLG case IDCANCEL: EndDialog(hwnd, IDCANCEL); // tried putting return 0; and return 1; here but still...Code://SECONDARY DLG case IDCANCEL: EndDialog(hwnd, 0); return 1;
Are all the other cases still using break instead of return?
It would seem the ID_CANCEL message from the second dialog is propogating into the message queue of the first.
Usually returning TRUE stops this... have you tried returning 0 (FALSE) both times?
Sorry to have taken so long to answer xD a toolbar is giving me a hard time...
But yes, having replaced every "break;" with a "return 1;" solved it and now it works, thanks again!
If you have modeless dialog [started with CreateDialog() as opposed to DialogBox()] you use DestroyWindow() [not EndDialog()]
It is not about failure of GetDlgItemInt() (occassions where GetLastError() returns anything but ERROR_SUCCESS)
GetDlgItemInt() will return '0' if the edit contains '0.123456789' or 'sometext' or if the edit empty.
How do you tell the difference between the user inputing '0' and no input?
I disagree with this. Learn to code WIN32 the 'correct' way before you start taking short-cuts with the syntax.
I would not allow any member of my dev team to write switch statements without using 'break'.
Not returning the correct value to show you have processed the message is the issue, not the 'break' (as I pointed out in my first post).
Using 'break' is not a problem for windows and is syntatically correct.
You must use 'break' in some callbacks or have multiple calls to DefWinProc() (ie to close the multi message handlers like WM_COMMAND and WM_NOTIFY).
Changing your pattern to return from any handlers is a much better option.
Code:case WM_HANDLED_MSG: return SomeMsgHandler(); break; case WM_UNHANDLED_MSG: //allow this one to fall thru to the default procesing break; return DefWinProc();
Last edited by novacain; 12-04-2010 at 10:04 PM.
"Man alone suffers so excruciatingly in the world that he was compelled to invent laughter."
Friedrich Nietzsche
"I spent a lot of my money on booze, birds and fast cars......the rest I squandered."
George Best
"If you are going through hell....keep going."
Winston Churchill
Ahh... now I see your point. Yes, in that case there would be no way to know.
I'll pretend you didn't say that.I disagree with this. Learn to code WIN32 the 'correct' way before you start taking short-cuts with the syntax.
They should use what works best in a given situation.I would not allow any member of my dev team to write switch statements without using 'break'.
And how do you plan to do that without using return?Not returning the correct value to show you have processed the message is the issue, not the 'break' (as I pointed out in my first post).
Except when you don't want to call DefWindowProc() after having handled a message. Passing "handled" messages on to the default procedure can cause some very strange behaviour in a Windows program. Like our friend's example where closing one window resulted in the closure of the one below it.Using 'break' is not a problem for windows and is syntatically correct.
DefWindowProc() is only for unhandled messages... for example where have a case for WM_COMMAND but only handle some of the values of WPARAM... You would call DefWindowProc() as the default case for unhandled values, but you do not want to call it for values you have dealt with in your code. Hense, you want to return from the message loop immediately after each handled message. And yes, in some message loops you will have multiple calls to return DefWindowProc().You must use 'break' in some callbacks or have multiple calls to DefWinProc() (ie to close the multi message handlers like WM_COMMAND and WM_NOTIFY).
Try some performance testing... using return in case statements can result in a significant performance boost in message intensive programs. The advantage over break is that the loop is terminated as soon as a message is handled, the system does not need to continue analysing sections of irrelevent code to find it's way out of nested switch statements like you would find for WM_COMMAND and WM_NOTIFY. Also placing your most frequent messages at the top of the loop is even faster as it cuts down on processing time spent tunneling into unnecessary switch and case statements to find them.
Last edited by CommonTater; 12-04-2010 at 10:30 PM.
Sorry if I was not clear.
I am all for using returns in case statements (look at the example I posted, I return the result of the msg handler function directly).
I am not in favor of ommitting the 'break', even if it is superfluous.
"Man alone suffers so excruciatingly in the world that he was compelled to invent laughter."
Friedrich Nietzsche
"I spent a lot of my money on booze, birds and fast cars......the rest I squandered."
George Best
"If you are going through hell....keep going."
Winston Churchill
Yeah but no serious person uses PellesC to do anything. It is to optimization what IE6 is to web standards
Since it's still followed... I've another simple question:
If I want to display a selected string from a Combobox, into a Static, by pressing a Button... what is missing/wrong here?:
I've noticed that at no point do I mention the IDC_COMBOBOX, but I've also tried withCode:char *buffer; case IDC_BUTTON: buffer = SendMessage(hwnd, CB_GETCURSEL, buffer, 0); SetDlgItemText(hwnd, IDC_STATIC7, buffer);
But still not working... Any suggestions? Thanks.Code:char *buffer; case IDC_BUTTON: buffer=GetDlgItemText(hwnd, IDC_COMBOBOX, buffer, TRUE); SetDlgItemText(hwnd, IDC_STATIC7, buffer);
So you can't put buffer in two places like that and expect it to hold both things, right? You should (first) make buffer point to somewhere reasonable, like a bunch of empty memory that you own and (second) call GetDlgItemText and don't assign the return value to buffer because the return value is just the number of characters stored. (And the fourth argument to GetDlgItemText isn't a boolean....)
A couple of ways you can do this:
The thing to keep in mind is that, by itself, EditBuf is just a pointer to an address in memory, you have to explicitly tell the compiler to reserve a block of <size> bytes for it to point to or create the block at runtime.Code://assume the text will never be more than 255 chars TCHAR EditBuf[255]; //array of chars //read text into array GetDlgItemText(hwnd, IDC_YOUREDIT, EditBuf, sizeof(EditBuf)); //see what's in EditBuf MessageBox(NULL,EditBuf,"Buffer Contents",MB_OK); -OR- //allocate buffer to explicit length of text (+1) TCHAR *EditBuf=NULL; //pointer to string //first, get length of editbox string int len = GetWindowTextLength(GetDlgItem(hwnd, IDC_YOUREDIT)); //allocate enough memory to hold string (+1) HGLOBAL hgbl = GlobalAlloc(GMEM_ZEROINIT, len+1); //if allocation succeded if (hgbl) { //point your buffer to allocated memory EditBuf=(TCHAR *)GlobalLock(hgbl; //read text into allocated memory GetDlgItemText(hwnd, IDC_YOUREDIT, EditBuf, len+1); } //else, if it didn't succeed else return 0; //see what's in EditBuf MessageBox(NULL,EditBuf,"Buffer Contents",MB_OK); //free allocated memory GlobalUnlock(hgbl); GlobalFree(hgbl); EditBuf=NULL; -OR- //for easier dynamic allocation TCHAR *EditBuf = new char[len+1]; //use buffer... //free allocated memory delete [] EditBuf;
You can do this either by static allocation, as is the case with an array[] or with a dynamic allocation, at runtime.
In either case, you need some reserved-bytes for EditBuf to point to before you can use it.
.
Last edited by morongo; 12-06-2010 at 02:29 PM.
You need memorry allocated for buffer... Simply declaring a variable does not do that.
Either use malloc or buffer[somesize];
Also: I see you're still putting code in switch case statements...Code:// to fetch from list to static void MoveCBListText(HWND hwnd) { char Buffer[256]; int idx; idx = SendDlgItemMessage(hwnd, IDC_COMBOBOX,CB_GETCURSEL,0,0) SendDlgItemMessage(hwnd, IDC_COMBOBOX,CB_GETLBTEXT,idx,0); SetDlgItemText(IDC_STATIC7,Buffer); } // to fetch from display to static void MoveCBDispText(HWND hwnd) { char buffer[256]; GetDlgItemText(hwnd, IDC_COMBOBOX,buffer,255); SetDlgItemText(hwnd,IDC_STATIC7,buffer); }
See the way I defined the functions above... creating a memory buffer and creating an int... Inside a prodedure these variable are created, the work is done, and they are destroyed when the function returns. Not only do you NOT have to define all these extra variables inside your message loop, memory usage is reduced because all these extra variables do not coexist...
Last edited by CommonTater; 12-06-2010 at 04:21 PM.