Forum

this seems to be a bug inside CExtScrollBar. We have a class derived from CExtScrollBar, inside the WindowProc, we found it received additional WM_HSCROLL message with wParam set to SB_THUMBPOSITION and SB_THUMBTRACK, whicn is incorrect as SB_THUMB... should be sent only when the user clicks the thumb.

The additional message is geneated inside


void CUfcScrollBar::_SetScrollPos( ...) function

if( bSendScrollingNotification && _psbd.m_bEnabled )

{

HWND hWndParent = ::GetParent( m_hWnd );
if( hWndParent != NULL )
{
::SendMessage(
hWndParent,
_psbd.m_bHorzBar ? WM_HSCROLL : WM_VSCROLL,
MAKEWPARAM(
( bTrackPos ? SB_THUMBTRACK : SB_THUMBPOSITION ),
nPos
),
LPARAM(m_hWnd)
);
}

change this line

if( bSendScrollingNotification && _psbd.m_bEnabled )

to

if( bSendScrollingNotification && _psbd.m_bEnabled &&

m_nSBMHT == CExtPaintManager::__ESBMHT_THUMB )

seems to fix the problem, any comments ?



thanks

Thank you for reporting us this issue. We agree that thumb button notifications should be sent during thumb button drag-n-drop only. But such notifications are very handy because WM_HSCROLL / WM_VSCROLL message handler methods are getting ready-to-use new scrolling position value. That is why we decided to send thumb button notifications for all the scroll bar events. We have accepted the fix you proposed and the updated version of the CExtScrollBar window will work with any other windows which can work with scroll bar common controls. But some of Prof-UIS classes require the always-sent thumb notifications. So, we will need to support both scroll bar modes. For instance, the CExtNCSB template class requires always-sent notifications and we will need to fix its source code too. We agree that default behavior of the CExtScrollBar class should be exactly the same as behavior of scroll bar common control. Please send us an e-mail to the support mail box and we will reply you with the source code update which contain all the required scroll bar fixes.