Breaking CScrollBar Range Limit

[Alhexx]

I'm currently writing a raw hex viewer control for my archive decompressor project called CHexViewCtrl. Here's a small screenshot.

The CHexViewCtrl class is derived directly from CWnd.
I have added a CScrollBar to give the user the possibility to scroll through the file.

However, the default MFC CScrollBar class has a maximum Scroll range of 32,767. This usually does not matter, since the class is able to handle bigger ranges now.

But there's a problem:
When receiving the SB_THUMBTRACK or SB_THUMBPOSITION message, the OnVScroll method of my derived class passes the current position in a variable called nPos (UINT). However, these two messages only give valid positions when the scrolling position is less than 32K.

Does anyone have an idea how to get around this problem and make the scrollbar want to cooperate with me?

 - Alhexx

EDIT: CHexViewCtrl is the name of the control, the name of the archive decompressor is Kaddy

[Cyberman]

I'm currently writing a raw hex viewer control for my archive decompressor project called CHexViewCtrl. Here's a small screenshot.

The CHexViewCtrl class is derived directly from CWnd.
I have added a CScrollBar to give the user the possibility to scroll through the file.

However, the default MFC CScrollBar class has a maximum Scroll range of 32,767. This usually does not matter, since the class is able to handle bigger ranges now.

But there's a problem:
When receiving the SB_THUMBTRACK or SB_THUMBPOSITION message, the OnVScroll method of my derived class passes the current position in a variable called nPos (UINT). However, these two messages only give valid positions when the scrolling position is less than 32K.

Does anyone have an idea how to get around this problem and make the scrollbar want to cooperate with me?

 - Alhexx

EDIT: CHexViewCtrl is the name of the control, the name of the archive decompressor is Kaddy

Sounds like a control issue.  There are a number of controls in the win API that do (dumb) things like this.  It's a dervided class you said? The Scroll units are derived as well? I use a draw grid for my hex view object I can view 32 meg files with it no problem.  There might be a bug in the class interface you are using OR you might be using a INT16 instead of an INT32.  It seems that somewhere it's getting to be a 16 bit int.  Where is a good question though.  I assume you are using C#?

Cyb

[L. Spiro]

Because of the nature of how the WPARAM works when used in conjunction with this message, it is only able to store a 16-bit value for the offset position of the scrollbar (HIWORD( wParam )).
I haven’t used MFC, but this is the reason your variable is only able to maintain the range up to 32,767 units.


So, in the case of these two messages, you should actually get the offset directly from the control:

Code: [Select]

SCROLLINFO si;
…

case SB_THUMBTRACK : {
}
case SB_THUMBPOSITION : {
si.cbSize = sizeof( si );
si.fMask  = SIF_TRACKPOS;
GetScrollInfo( m_hWnd, SB_VERT, &si );
yNewPos = si.nTrackPos;
break;
}


Here, my m_hWnd is a member of a class used for the base of a custom control.  m_hWnd is the HWND handle to the actual control that has the scrollbar (of course!).


yNewPos is, clearly, the new Y position of the scrollbar, in 32 bits.


L. Spiro

[Alhexx]

L. Spiro: Once again, you saved my life... your method works
So my scrollbar now suprorts files up to 32GB (!) size... hehe



 - Alhexx

[Cyberman]

L. Spiro: Once again, you saved my life... your method works
So my scrollbar now suprorts files up to 32GB (!) size... hehe
<TANX removed>
 - Alhexx

Glad someone was able to help you. Yes thanks for L. Spiro for pointing to the problem and not the fact it was a signed short int (LOL).

Cyb