Scrollbars


A Scrollbar can be created on its own OR as a builtin element of a window. The latter way occurs when WS_HSCROLL and/or WS_VSCROLL are specified in the style parameter flags at the window creation. In this situation scroll events will be sent to the window owner's handler. When scroll bars are made this way it has the advantage that they automatically resize as the window is resized. The disadvantage is that they are not quite so flexible as scroll bars created on their own are. To differentiate between scroll bar controls created on their own or as part of a window the user must pass a flag into getScrollInfo() or setScrollInfo() that indicates what type is being referred to.

procedure setScrollInfo(object id, sequence settings, integer fRedraw)
id - refers to the id of the ScrollBar or TrackBar or ProgressBar - for builtin scroll bars it's a sequence {Window, flag} where Window is the id of the owner window and flag is SB_HORZ or SB_VERT to specify correct bar.

settings - A list containing {Minimum, Maximum, PageSize, Position}, it can also have the additional item of TrackPos but you may never need it. - Scrollbars must have the 4 main items but for TrackBars only need the first 2 items are mandatory and the 5th possible item is never used. - For ProgressBars the interpretation of this parameter is {Minimum, Maximum, StepSize, Position} where StepSize refers to the amount that the pointer will advance in the next iteration.

fRedraw - Flag indicating whether the control needs to be redrawn after the settings have been updated. True for yes, False for no. - Has no effect for ProgressBars.

function getScrollInfo(object id)
id has the same meaning as in setScrollInfo(). The function will return a sequence of {Minimum, Maximum, PageSize, Position} for TrackBars but will return {Minimum, Maximum, PageSize, Position, TrackPos} for ScrollBars. Currently this function doesn't provide for Progressbars. If an error occurs then it will return {0,0,0,0,0}.

function getPos(object id)
Will return the current position of the ScrollBar, TrackBar or ProgressBar.

procedure setPos(object id, atom pos)
Sets the current position of the ScrollBar, TrackBar or ProgressBar. Builtin scroll bars will cause WM_HSCROLL or WM_VSCROLL messages to be sent to the handler routine of the owner window. The messages will pass the full 32-bit position of the scroll control.

ARWEN has been updated to separately manage independent scroll bars which are similar to those that can be created as attributes of a Window. Since builtin scroll bars are possible attributes of windows the user might inadvertently create them by invoking setScrollInfo() and passing the id of the Window. Now that you know about this anomaly you'll probably never make that mistake anyway. The reason ARWEN now manages independent scroll bars in this way is to overcome the limitations that the built-in scroll bars have. Independent scroll bars reside along the borders of the window and are automatically resized with the window. To create these scroll bars use the flags SBS_BOTTOMALIGN or SBS_RIGHTALIGN for Horizontal or Vertical scroll bars respectively,ie:

constant HHH = create(HScroll, "", 0, DEMO, 0,0,0,0, SBS_BOTTOMALIGN)
constant VVV = create(VScroll, "", 0, DEMO, 0,0,0,0, SBS_RIGHTALIGN)
The scroll bars will be created using the default width for scroll bars. You may change this by specifying the nWidth or nHeight fields for Vertical or Horizontal scroll bars respectively. All other dimensions are ignored when these special flags are used. The benefits of these managed scroll bars is that they are always perfectly positioned, ie, the vertical scroll bar is always beneath the ToolBar and above the StatusBar (if any) and the Horizontal scroll bar always sits above the StatusBar (if any). Access to these independent scroll bars is the same as to any other independent scroll bar because they are actual controls in their own right, not attributes of a window. You may still use the builtin scroll bars if you wish. As far as I can tell there is one advantage the built-in scroll bars have and that is where the pair of them exist (& are visible) then a size-box is automatically shown. I do not make any provision for emulating this behaviour. However, you may specify the SBARS_SIZEGRIP flag when creating a StatusBar which will then have a sizebox. Applications usually have a StatusBar but if your's didn't you could use the built-in scroll bars to ensure the use of the size-box. One drawback that the managed scroll bars have is that they are placed in the Client area and therefore may suffer interference from other controls such as Buttons, CheckBoxes etc.. I have not yet found an easy way to stop this but the user can limit the size of a window by trapping the WM_SIZING message which might help. Also, scroll bars seem likely only where the Client area is entirely user-drawn so this issue may not really be a problem at all.