Apache OpenOffice (AOO) Bugzilla – Issue 99704
Turn off mouse scroll in cells
Last modified: 2010-07-24 07:51:29 UTC
I need to turn off the ability to use mouse scroll increasing or decreasing a value in a form-cell (. It has dawned on my users that they constantly change values when they thought they were scrolling up and down the document.
I think this is a valid request for enhancement (RFE). As a workaround you can set the "increment value" to 0 in the properties, but then you can't change the value with the cursor buttons.
Thanks. That is good enough for me at this time.
The work-around refers to a form control. IMHO, the main issue is that all numeric fields (including dates×) in any plain grid-view of any writable row set behaves as described. When you scroll through such a grid you are always in danger to edit values accidentally.
I am sorry, but I just can't find where to set the "Increment value". Could I please get some directions to it? I tried the Controll, Properties under the right-click menue (see image at http://user.services.openoffice.org/en/forum/viewtopic.php?f=39&t=15427#p75715) I also tried elsewere at document properties etc. Please help
The present UI behaviour (up to at least 3.1.x) is that numeric values are incremented by 1.0 when the mouse is over a numeric cell, and the mouse wheel is scrolled up. Numbers are decremented by 1.0 when scrolled down. This behaviour is consistent in tables, queries and forms. In all versions of MS Access, the effect of a scroll wheel on a table or query scrolls the grid view up and down to navigate records. There is no difference if the mouse is over a numeric value or any other type. In older versions of Access (2003 and before), the effect of the scroll wheel on a database form navigates the records forwards and backwards. Values in fields can only change if typed (or cut/paste). Devs: please keep in mind the MS Access UI behaviour for migrating end-users. I highly recommend that the default behaviour of a scroll-wheel should *NOT* change the data *EVER*, since it too easily contaminates numeric data. Number data should only be typed in (or cut/paste). I see no reason why this was a good idea in the first place. This misfeature is dangerous and is why (unfortunately) we still need to keep buying MS Access for our office. Our data is valuable since it is our business. I've been checking this feature since 1.x, but is still an issue in 3.1.x. I would really love to migrate off MS Access to OO.o, but this is a deal breaker. I can't figure out the "increment value" workaround mentioned before either.
an earlier target than "later" sounds appropriate here.
fixed in CWS dba32c find more information about this CWS, like when it is available in the master builds, in EIS, the Environment Information System: http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fdba32c
The fix is two-stage: First, a property "Mouse wheel scroll" is introduced for various form controls (and also table control columns), with the possible values "Never", "When focused", and "Always". The default for this property is "When focused", which mimics the pre-fix behavior: A control will react on the mouse whee (and scroll/spin its content) if and only if the mouse hovers over the control, and the control has the focus. ("Never" means to ignore the wheel completely, "Always" means to drop the focus restriction.) Second, in the data view for tables/queries, this property is set to "Never", since in fact it doesn't really make sense to let a control, which is part of a scrollable context, consume and handle wheel events.
Adjust target.
fs->oj: please verify in CWS dba32c
Verified.
Checked in DEV300m_53 Win Dataview behavior, as described From controls, as described Grid column controls, almost - see http://dba.openoffice.org/issues/show_bug.cgi?id=103756 Closing this issue
I've got the same issue with numeric fields in a Writer dialog. I cannot find a mouse wheel property.