MoveWindow of a ComboBoxEx control

Robin Ehrlich

unread,

Jun 16, 2008, 11:55:00 AM6/16/08

to

Using the WIN32 API and standard resource files, I have created a dialog with
a ComboBoxEx control. When I try to move the ComboBoxEx control via the
MoveWindow API, the display rectangle for the ComboBoxEx becomes a white box.
No data is displayed and the dropdown arrow goes away.

After spending a lot of time trying to understand what I happening, I have
discovered the problem. The ComboBox is a child of the ComboBoxEx; however,
when the ComboBox moves itself or is moved by the parent, the move does not
take into account the parent/child relationship and the ComboBox is moved
relative to the parent dialog, not the parent (ComboBoxEx). Therefore the new
co-ordinates of the Comobox is completely wrong.

I have a Word document showing the results of SPY during the operation, but
I can't attach it here.

The solution I have used is to the following after moving the ComboBoxEx:

GetWindowRect(hWndComboBoxEx, &rc2);
hWnd2 = (HWND) SendMessage(hWndComboBoxEx, CBEM_GETCOMBOCONTROL, 0, 0);
MapWindowPoints(NULL, hWndComboBoxEx, (POINT *) &rc2, 2);
MoveWindow(hWnd2, rc2.left, rc2.top, rc2.right - rc2.left,rc2.bottom -
rc2.top, 0);

_@_roadrunner_com Ivo Beltchev

unread,

Jun 16, 2008, 12:12:18 PM6/16/08

to

That should not be necessary. The ComboBox is a child window and its position is relative to its parent, and you should never need to move it or resize it manually. You are doing something wrong. Maybe you are subclassing the ComboBoxEx and forget to let it handle WM_SIZE/WM_MOVE?

Also double-check with Spy++ that the ComboBox has the WS_CHILD style. Maybe you are messing with the styles and clear the WS_CHILD bit. Another thing to keep in mind is that combo boxes ignore the height when resized.

"Robin Ehrlich" <RobinE...@discussions.microsoft.com> wrote in message news:3A315466-C0CB-4DCD...@microsoft.com...

Robin Ehrlich

unread,

Jun 16, 2008, 12:24:00 PM6/16/08

to

Thank you for the response, but you are incorrect. I am not doing anything
wrong. I am not subclassing or changing any window flags.

I am reporting a bug in WIN32 ComboBoxEx handling of the MoveWindow. I know
that I should not have to move the ComboBox child window myself, the
ComboBoxEx should handle it correctly, but it doesn't.

Sam Hobbs

unread,

Jun 17, 2008, 7:46:35 AM6/17/08

to

You probably are doing something incorrect and it is unlikely that Windows
is doing something incorrect.

The "white box" you describe might be the result of not processing messages,
or processing them incorrectly.

"Robin Ehrlich" <RobinE...@discussions.microsoft.com> wrote in message

news:3227C13C-51D4-4236...@microsoft.com...

Robin Ehrlich

unread,

Jun 19, 2008, 3:21:03 PM6/19/08

to

I have output from Spy showing the error. Before my application issues the
MoveWindow() API call, the size and location of the ComboBoxEx and the child
combobox are the same. Immediately after the call, the ComboBoxEx window is
moved to the correct location, but the combobox window is at some other
location way off the dimensions of the parent dialog window.

Robin

Frank Cheng

unread,

Jun 23, 2008, 3:36:28 PM6/23/08

to

This is my plain vania version of what you are trying to describe. It's not
happening on my machine (Windows XP)

#define UNICODE
#include <windows.h>
#include <commctrl.h>
#pragma comment(linker,"/OPT:NOWIN98")

BOOL CALLBACK WndProc(HWND h, UINT MyMSG, WPARAM wp, LPARAM lp)
{
COMBOBOXEXITEM cbi;
switch (MyMSG)
{
case WM_COMMAND:
switch (wp)
{
case 2: EndDialog(h,0); break;
case 10: MoveWindow(GetDlgItem(h,11),0,0,100,100,TRUE); break;
}
break;
case WM_INITDIALOG:
cbi.mask = CBEIF_TEXT;
cbi.pszText = TEXT("Hello");
cbi.iItem = 0;
SendDlgItemMessage(h,11,CBEM_INSERTITEM,0,reinterpret_cast<LPARAM>(&cbi));
break;
}
return FALSE;
}

int WinMain(HINSTANCE hInstance,HINSTANCE,LPSTR lpCmdLine,int nCmdShow)
{
InitCommonControls();
DialogBoxParam(NULL,MAKEINTRESOURCE(1),NULL,WndProc,0);
ExitProcess(0);
return 0;
}

This is the RC file

//Microsoft Developer Studio generated resource script.
//
#include "resource.h"

#define APSTUDIO_READONLY_SYMBOLS
/////////////////////////////////////////////////////////////////////////////
//
// Generated from the TEXTINCLUDE 2 resource.
//
#include "afxres.h"

/////////////////////////////////////////////////////////////////////////////
#undef APSTUDIO_READONLY_SYMBOLS

/////////////////////////////////////////////////////////////////////////////
// English (U.S.) resources

#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_ENU)
#ifdef _WIN32
LANGUAGE LANG_ENGLISH, SUBLANG_ENGLISH_US
#pragma code_page(1252)
#endif //_WIN32

/////////////////////////////////////////////////////////////////////////////
//
// Dialog
//

#ifdef APSTUDIO_INVOKED
/////////////////////////////////////////////////////////////////////////////
//
// TEXTINCLUDE
//

1 TEXTINCLUDE DISCARDABLE
BEGIN
"resource.h\0"
END

2 TEXTINCLUDE DISCARDABLE
BEGIN
"#include ""afxres.h""\r\n"
"\0"
END

3 TEXTINCLUDE DISCARDABLE
BEGIN
"\r\n"
"\0"
END

#endif // APSTUDIO_INVOKED

#endif // English (U.S.) resources
/////////////////////////////////////////////////////////////////////////////

#ifndef APSTUDIO_INVOKED
/////////////////////////////////////////////////////////////////////////////
//
// Generated from the TEXTINCLUDE 3 resource.
//

/////////////////////////////////////////////////////////////////////////////
#endif // not APSTUDIO_INVOKED

"Robin Ehrlich" <RobinE...@discussions.microsoft.com> 撰寫於郵件新聞:51F98C5E-D0FB-49BB...@microsoft.com...

Robin Ehrlich

unread,

Jun 24, 2008, 12:41:00 PM6/24/08

to

Thank you very much for the sample program. I discovered a subtle error in my
program in the handling of child windows that caused me to move both the
ComboBoxEx and the child ComboBox. I apologize reporting the error
erroneously. I really thought my code was correct.

Robin

"Frank Cheng" wrote:

Sam Hobbs

unread,

Jun 24, 2008, 3:17:26 PM6/24/08

to

That often happens. I have done that. The important lesson for the future is
to understand the importance of being verifying assumptions. We often assume
things work but we often need to confirm they do.

"Robin Ehrlich" <RobinE...@discussions.microsoft.com> wrote in message

news:1C23F0AD-C79D-441A...@microsoft.com...