Thread: Simple WinAPI code problem.

If you have modeless dialog [started with CreateDialog() as opposed to DialogBox()] you use DestroyWindow() [not EndDialog()]

Originally Posted by CommonTater

The lpTranslated flag doesn't catch bad data... it gives an indication whether the function call suceeded or not. Causes of failure would be things like an invalid window handle, an invalid dialog item number, etc. but not the content of the edit box. If you type "hello" then call GetDlgItemInt() it simply returns 0....

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?

Originally Posted by CommonTater

windows doesn't like case statements with break in them. You should always use return as shown.

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();

Originally Posted by novacain

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?

Ahh... now I see your point. Yes, in that case there would be no way to know.

I disagree with this. Learn to code WIN32 the 'correct' way before you start taking short-cuts with the syntax.

I'll pretend you didn't say that.

I would not allow any member of my dev team to write switch statements without using 'break'.

They should use what works best in a given situation.

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).

And how do you plan to do that without using return?

Using 'break' is not a problem for windows and is syntatically correct.

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.

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).

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().

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.

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.

Originally Posted by Pecado

But still not working... Any suggestions? Thanks.

A couple of ways you can do this:

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;

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.

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.
.

Originally Posted by Pecado

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?:

Code:

char *buffer;

           case IDC_BUTTON:
                buffer = SendMessage(hwnd, CB_GETCURSEL, buffer, 0);
		SetDlgItemText(hwnd, IDC_STATIC7, buffer);

I've noticed that at no point do I mention the IDC_COMBOBOX, but I've also tried with

Code:

char *buffer;

           case IDC_BUTTON:
               buffer=GetDlgItemText(hwnd, IDC_COMBOBOX, buffer, TRUE);
               SetDlgItemText(hwnd, IDC_STATIC7, buffer);

But still not working... Any suggestions? Thanks.

You need memorry allocated for buffer... Simply declaring a variable does not do that.
Either use malloc or buffer[somesize];

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); 
    }

Also: I see you're still putting code in switch case statements...

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...