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.