Menu
▾
▴
#381 Provide an option for separate scrollbar controls on Windows
The MS Windows version of the Scintilla control
uses "window" scrollbars - that is, the automatic
scrollbars that any window can have, via the
WS_VSCROLL | WS_HSCROLL styles. It would be nice if
there were an option to tell the control to use
separate scrollbar controls instead.
Here's why: a window's automatic scrollbars can't be
customized in any way, whereas explicit, separate
scrollbars can be. The particular situation I'm
dealing with is that I need to be able to resize the
scrollbars slightly, so that they don't take up the
full height/width of the window. I need to insert an
extra control at one end of the scrollbar - in this
case a splitter control, but there are other times
when it's useful to be able to insert an extra
control along the scrollbar perimeter.
I'm attaching a copy of win32/ScintillaWin.cxx with
what I think are the necessary changes. It works as
follows: if the Scintilla window is created *with*
the WS_VSCROLL | WS_HSCROLL styles, everything works
as normal, with the standard window scrollbars. But
if the window is created *without* those styles, the
Scintilla window creates separate scrollbar and size-
grip controls. Wherever the window scrollbars are
mentioned in the code, I've made the necessary
changes to manipulate the automatic or separate
scrollbars as appropriate. In addition,
GetClientRectangle() subtracts out the space used by
the separate scrollbars if necessary.
There are two things I'm concerned about in my
implementation that might merit further work.
First, there's no provision for the scrollbars
becoming invisible; I use SIF_DISABLENOSCROLL
instead, to disable the scrollbars if the range makes
them unnecessary. This is slightly different from
the standard behavior, but actually more consistent
with current Win UI guidelines.
Second, more importantly, I'm not sure about my
strategy of using the *absence* of WS_VSCROLL |
WS_HSCROLL to activate this mode. It's conceivable
that some existing code intentionally omits these
style bits because it explicitly wants no scrollbars
to be shown. It would probably be better to define a
new style flag special to the Scintilla control -
SCIS_SEPARATE_SCROLLBARS, say - that activates this
mode explicitly. I think this would have to be via a
style bit rather than, say, a new SCI_xxx messages,
since otherwise the automatic window scrollbars would
probably be configured already by the time the new
SCI_xxx message could be sent.
win32/ScintillaWin.cxx, with changes to optionally use separate scrollbar controls
Logged In: NO
Oops, forgot to include my email in the original detail field. It's mjr_@hotmail.com.
Logged In: YES
user_id=12579
Have you looked at how this is handled in wxWidgets'
wxStyledTextCtrl? The proposed modification implements only
one of a set of approaches to this issue. Sometimes the
container wants to be creating and controlling the scroll
bars such as when using a multipane container. The
modification only provides a vertical scroll bar. The
application may devise an interface with custom scroll bar
components. And so on. More generally useful would be API
support that would allow the container to implement any of
these options and integrate them with Scintilla.
Logged In: YES
user_id=12579
I should have said that the extra graybox/sizegrip only
appears in the vertical scroll area rather than "The
modification only provides a vertical scroll bar."
Logged In: NO
I agree that a full scrollbar customization API would be better. But that's way beyond
what I'd have time to implement right now, so I wanted to at least propose these changes,
since they do what I need at the moment and are very simple and low-impact. Note that
because the scrollbars and size grip become first-class controls in this set-up, you can
actually do quite a lot of customization, at least in win32-specific code - the container
can move/resize and owner-draw the scrollbars by subclassing (in the win32 sense of the
word) the Scintilla HWND or the individual control HWNDs. But, yes, it's not flexible
enough for something like a shared vertical scrollbar in a split-pane view, so if a full
container-scrollbar API is envisioned at some point, it probably wouldn't be worth
muddying the waters by adding this as well.
--mjr@hotmail.com
Old feature request, but I'd like to up-vote this. I just need the ability to style the scrollbar with simple WM_CTLCOLOR notification responses.
Any thoughts to digging this back out, Neil?
This is not a current area of interest to me.
Does that mean you'd not accept someone else doing the work and accepting a patch? Or you're only leaving this feature request open because eventually you might consider it but for the foreseeable future its a "no"?
Depends on how it is done.
I needed to customize the scrollbars myself for dark theme applications. The default scrollbars are always the system default and there is no way to custom paint them.
I've attached my changes to Scintilla 4.20.
Scintilla already pipes all scrollbar updates via ScintillaWin::SetScrollInfo and ScintillaWin::GetScrollInfo. The core change is to allow Scintilla to set and get scroll info from a custom scrollbar.
I did this by adding a single new message that allows users to set custom scrollbars. The custom scrollbars are not owned by Scintilla, it's just what Scintilla now uses for SetScrollInfo/GetScrollInfo.
SCI_SETSCROLLBAR
wParam = int nBar (SB_HORZ or SB_VERT)
lParam = HWND hBar (HWND of user "SCROLLBAR" class window, or NULL to restore default)
The user can pass any scrollbar of their choosing. It's up to the user to manage positioning of the scrollbars. It's also left up to the user to add their own size-gripper and position it accordingly with the scrollbars. It gives the user a lot of flexibility.
The user must forward WM_HSCROLL and WM_VSCROLL notifications to Scintilla so that Scintilla can perform the scrolling.
The only thing managed by Scintilla is scrollbar visibility. The two options are to auto-hide the scrollbar when it's not needed or auto-disable. This could be a scintilla style flag but my implementation currently checks the initial visibility state of the custom scrollbar (WS_VISIBLE). If the scrollbar is visible then it will be auto-disabled, if it starts off hidden then it will use auto-hide. The user can always toggle the visibility state before calling SCI_SETSCROLLBAR to control this option.
Auto-hide can affect user layout so a notification needs to be sent to the parent. Currently just using ContainerNeedsUpdate with SC_UPDATE_H_SCROLL/SC_UPDATE_V_SCROLL when auto-hide state changes.
I don't know how to use scintilla.iface so I just hardcode SCI_SETSCROLLBAR into scintilla.h for my change.
I've attached a simple MFC (to avoid all of the Win32 boiler plate code) test app to demostrate the change.
Last edit: Piotr Mintus 2019-08-17
I have examined the change but not fully. The feature is more Win32-specific than most Scintilla APIs.
The extra complexity of managing scrollbar visibility is troubling as it seems to stray too far into policy and I can't tell if this is needed to function or its there to simplify clients.
A simpler implementation may be more attractive. If this isn't committed then it may be possible to add an extension point that would simplify its separate maintenance.