Issue 14570

correcting sub component (see
http://www.openoffice.org/issues/describecomponents.cgi?component=database%20access)

assigning to QA

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 ...

Sure. Use the sample form attached to issue 14571 and try to scroll 
through it using the scroll wheel.

confirming
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 :)

Created attachment 6542 [details]
sample doc to reproduce the bug case

attached the document from issue 14571 here, for easier handling

FME->MT: There are a couple of multi line edit controls in this
document. Seems like they do not pass the scroll wheel event.

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...

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?

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 
GETSCROLLWHEELEVENTSWITHOUTFOCUS.

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
inconvenient.

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 :).

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.

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
controls).

this is no crash, thus removing dependency to issue 21786

SBA: Target set to "OOo later".

SSA: reassign to HDU

Accepting this heritage...

Reset assigne to the default "issues@openoffice.apache.org".