Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles
(untagged)

Owner drawn spin button control with autodisabling arrow buttons.

0.00/5 (No votes)
24 Jan 2000 1  
A spin button whose arrows automatically disable themselves when they are at their maximum or minimum value.

Sample Image - lbspin.jpg

There are many occasions where it's nice to have spin button control with autodisabling arrow buttons. The CLBSpinButtonCtrl class adds this feature to the default behavior of standard CSpinButtonCtrl.

How to use CLBSpinButtonCtrl

  1. Add LBSpinButtonCtrl.h and LBSpinButtonCtrl.cpp to your project.
  2. Include LBSpinButtonCtrl.h file to the desired class header file.
    #include "LBSpinButtonCtrl.h"; 
  3. Add a member variable to the desired class (CDialog, CFormView, etc.)
     CLBSpinButtonCtrl m_Spin;
  4. Subclass the spin control variable just created.
    void CYourDlg::DoDataExchange(CDataExchange* pDX)
    {
       CDialog::DoDataExchange(pDX);
       //{{AFX_DATA_MAP(CYourDlg)
    
       DDX_Control(pDX, IDC_SPIN, m_Spin);
       //}}AFX_DATA_MAP
    
    }
    

    Note: The custom behaivor of CLBSpinButtonCtrl is to switch off automatically if the style UDS_WRAP was applied to the control.

How it works

1. Overview

The CLBSpinButtonCtrl is owner drawn up-down control. To make its job this control handles the following messages:

    <LI><CODE>WM_PAINT
  • UDN_DELTAPOS
  • UDM_SETRANGE32
  • UDM_SETRANGE
  • UDM_SETBUDDY
  • WM_ERASEBKGND
  • WM_LBUTTONDOWN
  • WM_LBUTTONUP
  • WM_DESTROY

It also overrides virtual member functions of CSpinButtonCtrl:

  • PreSubclassWindow
  • WindowProc

The WH_CALLWNDPROC hook is used to update control's state when user enters or paste new values into corresponding buddy window (if such window exist).

Note:There is an possibility to switch off /on the custom behaivor of CLBSpinButtonCtrl, using its public member function [bool SetAutoDisable(bool bSetOn)].

2. Handling of notification message UDN_DELTAPOS

The UDN_DELTAPOS notification is sent before the WM_VSCROLL or WM_HSCROLL message, which actually changes the control's position. This lets me examine, allow, modify, or disallow the change.

The UDN_DELTAPOS is processed as reflected message.

If new position of spin control is the same as previous one, what can happen only when user clicked a disable arrow, then the handler eat UDN_DELTAPOS message.

Otherwise the control updates its state, depending on its new position and let UDN_DELTAPOS to be processed by system.

3. Handling of WM_PAINT message

  1. First of all to get rid of flickering we are drawing to memory DC (dc). So we have to create compatible memory DC and select bitmap into it.
    CPaintDC RealDC(this);
    CDC dc;
    CBitmap bmpMem,*pOldMemBmp;
    dc.CreateCompatibleDC(&RealDC);
    bmpMem.CreateCompatibleBitmap(&RealDC, rctPaint.Width(),
                                 rctPaint.Height());
    pOldMemBmp=dc.SelectObject(&bmpMem);
        
    // As  so we are bypassing WM_ERASEBCKGND, by returning TRUE from its 
    
    //handler - let's do its job here 
    
    dc.FillSolidRect(&rctPaint,::GetSysColor(COLOR_BTNFACE));
    
  2. Then we draw control using DrawFrameControl API
    // or DFCS_SCROLLLEFT
    
    dc.DrawFrameControl(&rcPaintUp,DFC_SCROLL,DFCS_SCROLLUP); 
    // or DFCS_SCROLLRIGHT
    
    dc.DrawFrameControl(&rcPaintDown,DFC_SCROLL,DFCS_SCROLLDOWN); 
    
  3. After that, we check control alignment and if we it is inside buddy, then we have to draw buddy's border around CLBSpinButtonCtrl.
  4. Then we check the current position of control, and if it reached the limit, we draw corresponding part of control as disabled, using BitBlt and advanced ROP codes.
  5. On the next step we check if control's position has changed,since previous call to OnPaint,if so we have to draw corresponding part of control as pressed. It is done using BitBlt and dc.MoveTo/LineTo API.
  6. At the final step we copy the resulting bitmap from memory DC to the screen, using BitBlt with SRCCOPY ROP.

4. The WH_CALLWNDPROC hook

If control has buddy window and it is of 'Edit' class, then control have to update its enabled/disabled state when contents of buddy window is changing. For instance, if user enters into buddy window the value greater than upper possible limit - it is obvious that the increasing arrow should switch to disable state. The best way to do it - create WH_CALLWNDPROC hook and test within it if EN_UPDATE message came from buddy window. Another posibility is in setting keyboard hook, but then user can foolish the control, using clipboard Copy/Cut/Paste functions.

As so I use a single WH_CALLWNDPROC hook for all existing in an application controls of class CLBSpinButtonCtrl, I need to distinguish between these controls in the static hook handler FilterBuddyMsgProc. For this purpose I used static std:map<HWND,HWND> gHandleMap, where key is handle to buddy window and assosiated value is handle to the spin control window.

Here is source code , used to install hook:

if(::IsWindow(m_hWndBuddy))
{
   char buf[5];
   ::GetClassName(m_hWndBuddy,buf,sizeof(buf)/sizeof(buf[0]));

   if(!strcmp(buf,"Edit"))
   {
      //The class  of buddy is Edit

      m_bBuddyIsEdit=true;
    
      //Test if WH_CALLWNDPROC hook already was installed.

      // If no, set up it.

      if(ghHook==NULL)
         ghHook=SetWindowsHookEx(WH_CALLWNDPROC,FilterBuddyMsgProc,NULL,
                                GetCurrentThreadId());

      //Try to find m_hWndBuddy in the gHandleMap

      HWNDMAP::iterator iterHwnd=gHandleMap.find(m_hWndBuddy);
      if(iterHwnd != gHandleMap.end())
      {
         if((*iterHwnd).second != m_hWnd)
         {
            //If in the gHandleMap already defined  another 

            //CLBSpinButtonCtrl for that buddy (m_hWndBuddy), then 

            //redefine it .

            gHandleMap.erase(iterHwnd);    
            gHandleMap.insert(HWNDMAP::value_type(m_hWndBuddy,m_hWnd));
         }
      }
      else
         //If the CLBSpinButtonCtrl assosiated with

         //m_hWndBuddy is not found in the gHandleMap, then add it.

         gHandleMap.insert(HWNDMAP::value_type(m_hWndBuddy,m_hWnd));
   }
}

Here is how my WH_CALLWNDPROC hook works:

LRESULT CALLBACK FilterBuddyMsgProc(  int code,  WPARAM wParam,  
                                      LPARAM lParam )
{
    CWPSTRUCT* pData=reinterpret_cast<CWPSTRUCT*>(lParam);
    if(WM_COMMAND==pData->message && EN_UPDATE==HIWORD(pData->wParam))
    {
        //If the incoming message is EN_UPDATE

        HWNDMAP::iterator iterHwnd = 
                   gHandleMap.find(reinterpret_cast<HWND>(pData->lParam));
        if(iterHwnd != gHandleMap.end())
        {
            //The incoming EN_UPDATE message has been sent

            //to the edit control, defined in the gHandleMap.


            //So, let's get the value, entered into the edit control

            //and send it to the CLBSpinButtonCtrl, assosiated

            //with the edit control.

            CString strText;
            int nLen=::GetWindowTextLength((*iterHwnd).first);
            ::GetWindowText((*iterHwnd).first,
                            strText.GetBufferSetLength(nLen),nLen+1);
            strText.ReleaseBuffer();

            //In case UDS_NOTHOUSANDS style not applied

            //we have to delete thousands delimiter from string

            strText.Remove((TCHAR)0xA0);

            NMUPDOWN nmUpDn;
            nmUpDn.iDelta=0;
            nmUpDn.iPos=atoi(strText);
            nmUpDn.hdr.code=UDN_DELTAPOS;
            nmUpDn.hdr.hwndFrom=(*iterHwnd).second;
            nmUpDn.hdr.idFrom=::GetDlgCtrlID((*iterHwnd).second);

            HWND hWndSpinParent=::GetParent((*iterHwnd).second);
            ::SendMessage(::GetParent((*iterHwnd).second),
                            WM_NOTIFY,(WPARAM)nmUpDn.hdr.idFrom,
                            (LPARAM)&nmUpDn);
        }
    }
    return CallNextHookEx(ghHook,code,wParam,lParam);
}

5. Handling WM_DESTROY message

When the CLBSpinButtonCtrl window is being destroyed, we have to remove buddy/spin association from the gHandleMap and if it is the last control, defined in the gHandleMap, then remove a hook procedure. This is done in member function CleanUpHook().

void CLBSpinButtonCtrl::CleanUpHook() const
{
    if(m_bBuddyIsEdit)
    {
        //If the buddy is edit, then try to find out if

        //it was added to gHandleMap.

        HWNDMAP::iterator iterHwnd=gHandleMap.find(m_hWndBuddy);
        if(iterHwnd != gHandleMap.end() && (*iterHwnd).second == m_hWnd)
        {
            //If m_hWndBuddy found and is assosiated with current window,

            //then delete it from gHandleMap.

            iterHwnd = gHandleMap.erase(iterHwnd);
            if(!gHandleMap.size() && ghHook!=NULL)
            {
                //If just deleted from the gHandleMap m_hWndBuddy was

                //the last for current application,

                //then remove a hook procedure. 

                UnhookWindowsHookEx( ghHook);
                ghHook=NULL;
            }
        }
    }
}

6. Handling of UDM_SETRANGE, UDM_SETRANGE32 messages

As so these messages can be used at runtime to set/change the minimum and maximum positions (limits) for a spin control. We have to to reinit CLBSpinButtonCtrl.

7. Handling of UDM_SETBUDDY message

This message sets/changes the buddy window for an up-down control, so we need to make corresponding updates to CLBSpinButtonCtrl too (call to CleanUpHook and reinit ).

7.1. Buggy handling UDM_SETBUDDY by common up-down control

When I was testing the UDM_SETBUDDY handling by CLBSpinButtonCtrl I've discovered a visual bug. If buddy window (m_hWndBuddy) is placed after this CLBSpinButtonCtrl in Z-order , then m_hWndBuddywindow will get WM_PAINT message after this CLBSpinButtonCtrl control and in case CLBSpinButtonCtrl is attached to buddy, it will be overpainted by buddy's border.

This undocumented bug persists for CSpinButtonCtrl as well.

To reproduce it create on dialog template CEdit control and right (with UDS_ALIGNRIGHT style) or left ( with UDS_ALIGNLEFT style) attached CSpinButtonCtrl control. Then make tab order so, that for CSpinButtonCtrl the tab position was less then for CEdit. After that in OnInitDiaolg call SetBuddy(pointerToEdit) function of CSpinButtonCtrl. Finally you will see the bug:

Below the same picture is enlarged:

I've worked around this by placing CSpinButtonCtrl after it's buddy in Z-order, using SetWindowPos API:
::SetWindowPos(m_hWndOfSpin,m_hWndOfBuddy,0,0,0,0, SWP_NOMOVE|SWP_NOSIZE);

Standard Disclaimer

These files may be redistributed unmodified by any means providing it is not sold for profit without the authors written consent, and providing that the authors name and all copyright notices remains intact. This code may be used in compiled form in any way you wish with the following conditions:

If the source code is used in any commercial product then a statement along the lines of "Portions Copyright (C) 1999 Oleg Lobach" must be included in the startup banner or "About" box or printed documentation. The source code may not be compiled into a standalone library and sold for profit. In any other cases the code is free to whoever wants it anyway!

This software is provided "as is" without express or implied warranty. Use it at you own risk! The author accepts no liability for any damages to your computer or data these products may cause.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here