Issue 14570 - Scroll wheel gets stuck on forms
Summary: Scroll wheel gets stuck on forms
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 1.1 Beta
Hardware: PC Windows 2000
: P3 Trivial (vote)
Target Milestone: AOO PleaseHelp
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2003-05-17 16:49 UTC by schulten
Modified: 2017-05-20 11:29 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

sample doc to reproduce the bug case (14.92 KB, application/octet-stream)
2003-05-30 12:05 UTC, Frank Schönheit
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description schulten 2003-05-17 16:49:55 UTC
A writer form of several pages (no db form, just text form with multiline form 
controls) cannot be fully scrolled using the mouse wheel. Scrolling stops at an 
undefined point, and you have to click somewhere in the form to get scrolling 
back. This does not affect pgup/dn, only the mousewheel gets stuck.
Comment 1 Frank Schönheit 2003-05-30 10:53:33 UTC
correcting sub component (see

assigning to QA
Comment 2 Frank Schönheit 2003-05-30 10:54:47 UTC
Dietrich, could you attach a sample document to show this? From a
quick test, I could not reproduce this - which may be due to the fact
that your bug description is rather ... sparse :) this time, and keeps
some questions open ...
Comment 3 schulten 2003-05-30 11:44:54 UTC
Sure. Use the sample form attached to issue 14571 and try to scroll 
through it using the scroll wheel.
Comment 4 Frank Schönheit 2003-05-30 12:04:51 UTC
changing QA component/component to Writer - this pretty much looks like
  a Writer core problem
targeting to 2.0
assigning to responsible (hopefully :) developer

fs->fme: if I was wrong with my guess that this is yours, I apologize
- please re-assign in this case :)
Comment 5 Frank Schönheit 2003-05-30 12:05:39 UTC
Created attachment 6542 [details]
sample doc to reproduce the bug case
Comment 6 Frank Schönheit 2003-05-30 12:06:06 UTC
attached the document from issue 14571 here, for easier handling
Comment 7 frank.meies 2003-06-05 07:40:32 UTC
FME->MT: There are a couple of multi line edit controls in this
document. Seems like they do not pass the scroll wheel event.
Comment 8 malte_timmermann 2003-06-19 17:21:38 UTC
Sure they don't pass them back, because MultiLineEdits support them.
Same behaviour when mouse is over DD-List-Box.
I think from the view of the controls it's correct.
Maybe they shouldn't consume the events when they don't perform an 
action, because there is nothing more to scroll, but that would mean 
in the case of the dd-List-Box, that they perform some actions before 
stopping consuming the event, and I don't think that this is what the 
user wants, so maybe we need a solution to prevent any controls in a 
document from receiving scroll events...
Comment 9 schulten 2003-07-16 11:35:54 UTC
Do you think it possible to support scrollwheels inside multiline 
edits, grids and dropdown listboxes without catching the focus? Why 
is it impossible not to catch the focus while the page scrolls by?
Comment 10 malte_timmermann 2003-07-16 11:54:33 UTC
The controls don't catch the focus, VCL sends scroll wheel commands 
to the window under the mouse pointer, regardless whether it has the 
focus or not.

May be this is the solution: Give the Window a flag not to receive 
scroll wheel events when not focused.

SSA, what do you think? If VCL offers that, this should IMHO become 
the default behavior for all VCL controls, not only for forms.
IMHO the current bahavior make only sense for documents, so maybe 
these kind of windows should set a flag for 
Comment 11 Frank Schönheit 2003-07-16 13:42:56 UTC
Sorry, I don't think that this is a good idea. If I understand you
correctly, then this means that I always have to focus a control
before I can use the scroll wheel on it. I think this is very

I suppose there is a reason why Logitec chose to implement exactly the
"scroll the window which is nearest to the mouse pointer, regeardless
of the focus" behaviour for the mouse drivers, and I suppose it's
called usability :).
(for Logitec, this in fact is a driver feature, which can be switched
on (or off?) with "Use MS office compatible scroll behaviour only", or so)

Also Mozilla, which also does have an own toolkit for the form
controls in their browser, does not require the focus for wheel events
to be handled.

Instead I think that the approach suggested first is the better one:
Do not consume wheel events when they're not handled. Isn't this a
general idea for event handling, anyway?
The disadvantage described for the list box wouldn't be too bad, IMO.
Not to mention that exactly this listbox behaviour can be observed in
Mozilla Browser, too, so we would have at least one product which we
are consistent with :).
Comment 12 Frank Schönheit 2003-07-16 13:52:26 UTC
another remark:
If the scroll wheel would always affect the focused window, then this
will confuse users: It means that you point to one item on your
desktop (or whereever), and scroll, and a control/window in a
completely different corner is affected. I think this would be pretty
strange, as people tend to associate the mouse pointer location with
the location where a mouse action happens. (it would be strange if
your mouse click does _not_ affect the window you're pointing at,
wouldn't it? :)

OTOH, if we say that controls/windows on which the user scrolls
(means: s/he points to it and scrolls) do _not_ scroll when not
focused, but completely absorb the scroll event, then we have the
original situation of this bug.

If we say that such controls do not scroll, and not absorb the event,
then we have the problem I mentioned above that you always need to
focus for scrolling.

From a usability perspective, and IMHO of course :), I think the most
negliable glitch is the list box which first scrolls their content,
and then the surrounding document.
Comment 13 stephan_schaefer 2003-07-21 17:21:32 UTC
After discussing this with MT again, the following solution seems to
be feasible: VCL will support a flag that lets windows ignore scroll
events when they are currently not focussed. This flag is by default
off, which means nothing will change. The only controls that will have
this flag changed are the form controls that are instantiated through
the toolkit and thus are easily detectable. 
This solution would ease scrolling through documents but would not
change the whole UI scrolling experience (eg, for dialog or toolbar
Comment 14 Frank Schönheit 2003-10-28 07:09:00 UTC
this is no crash, thus removing dependency to issue 21786
Comment 15 stefan.baltzer 2004-05-18 13:21:02 UTC
SBA: Target set to "OOo later".
Comment 16 stephan_schaefer 2005-12-02 11:10:17 UTC
SSA: reassign to HDU
Comment 17 2005-12-02 12:09:00 UTC
Accepting this heritage...
Comment 18 Marcus 2017-05-20 11:29:46 UTC
Reset assigne to the default "".