The down arrow of the msctls_updown32 control can fail to display under certain conditions using certain Windows Desktop themes

Question

I have a very odd issue with the msctls_updow32 control. Depending on the type of window or window heirarchy, when I click the up arrow with the autobuddy being an edit control, the down arrow disappears off the down button. I have to move the mouse back
over the down button to get it to display. At first I figured it was something in my OnCtlColor code. But I found that the updown control is never passed to OnCtlColor. I get the window class of each input and it never shows up. Nor does it's window handle
get passed in. Turning off OnCtlColor code and going default doesn't help. What I have found that helps is to turn off WIndows 7 Aero desktop and turn on Windows Classic desktop (Windows 7 Basic has the issue too). I also found that applying a skin to my app
avoids the issue. Using spy I finally found what appears to be a connection to EM_SETSEL. When that message is sent and processed, the arrow has disappeared. I finally gave up and created my own subclass of a CEdit control (MFC) and called SubclassDlgItem.
Then I implemented WindowProc and trapped the EM_SETSEL. Then I had to call UpdateWindow on the spin control and finally get the rectangle of the edit (buddy) and spin control and use that in a call to the parent (dialog) window's RedrawWindow.
 So there appears to be an issue with the updown control paired with an edit control that shows up depending on what desktop theme I am using. And to top it off, the window heirarchy seems to matter too (or perhaps the styles of the parent make a difference
as I found the issue doesn't show up on every window that may contain such a configuration). Consider this a heads up regarding the issue! One other note, changing to any of the "High contrast" Windows 7 desktops also avoids the issue. So Aero and
Basic seem to be the key.
R.D. Holland

Answer 1

Fails on Win 8.1 too. As with Win 7, changing the desktop display to one of the high contrast ones avoids the problem. My work-around is below. I have a video showing the problem. It also shows the display being changed to high contrast and how the problem
goes away. If only I could figure out how to use this web page to upload the zip file containing the video ...
LRESULT Myedit::WindowProc( UINT message, WPARAM wParam, LPARAM lParam )
LRESULT lr = CEdit::WindowProc( message, wParam, lParam );
if( message == EM_SETSEL )
CDialog* pParent = (CDialog*) GetParent();
if( pParent )
CSpinButtonCtrl* pSpin = (CSpinButtonCtrl*)pParent->GetDlgItem(IDC_SMALL_PARTS_SPIN);
if (pSpin)
CRect rectSpin;
pSpin->GetWindowRect( &rectSpin );
CRect rectEdit;
GetWindowRect( &rectEdit );
CRect both;
both.UnionRect( &rectSpin, &rectEdit );
pParent->ScreenToClient( &both );
//pParent->InvalidateRect( &both );
//pParent->Invalidate();
//pSpin->Invalidate();
pSpin->UpdateWindow();// skip this and the problem remains.
pParent->RedrawWindow(&both);// skip this and the problem remains.
return lr;
R.D. Holland