Issue 41977 - View > Zoom doesn't inform the user about the limits of values that can be entered
Summary: View > Zoom doesn't inform the user about the limits of values that can be en...
Status: CONFIRMED
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: 680m74
Hardware: All All
: P4 Trivial (vote)
Target Milestone: AOO Later
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords: oooqa
Depends on:
Blocks:
 
Reported: 2005-02-03 14:34 UTC by aparan
Modified: 2013-02-07 22:43 UTC (History)
2 users (show)

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

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description aparan 2005-02-03 14:34:26 UTC 
Open writer and some document.  GO to view > zoom > variable and enter 100000 in
the box over there.  Writer doesn't tell you that there is a max. limit [600%]
or a minimum [20%] for zoom values. Please see.

This is the case not only for writer, but for other apps. too [the limits vary
in those cases]
Comment 1 tkeon168 2005-02-06 20:35:56 UTC 
(Kevin Helms, 02/06/2005)

I was able to confirm this behavior for build 680m74 running on Solaris 8. 

If the value entered was above 600% or below 20%, then the zoom performed was 
only to the limit.  This could be confirmed by selecting view -> zoom again and 
observing the value entered for the variable. 

No inidcation was given by the program that it was using a value different than 
the one that was entered.
Comment 2 tkeon168 2005-02-06 20:42:01 UTC 
(Kevin Helms, 2/6/2005)

Additionaly, I tested the same behavior on WordPerfect 11 and Word 2003 and 
found that both applications provided an error dialog box stating the limits of 
the values.
Comment 3 haxwell 2005-02-09 00:52:30 UTC 
Confirmed. No message is given when a number outside of the allowed range is
entered.
Comment 4 cemkaner 2005-03-16 17:24:11 UTC 
My impression is that it is common practice in Open Office to silently repair
entries rather than giving messages. That is, I believe, part of the philosophy
of the UI of the old (1.0 and before) OOo products. 

(a) If the philosophy is the same, this is not a bug. (I might not agree with
the philosophy, but consistency of UI presentation is very important. Once a
baseline design decision is made, the design has to conform to the decision or
the broad decision has to go.)

(b) If the philosophy has changed, then this is the tip of a bugberg and we
should start doing a lot of testing for similar problems with other fields.
Comment 5 thorsten.martens 2005-04-06 15:08:59 UTC 
Please have a look.
Comment 6 ace_dent 2008-05-16 00:38:34 UTC 
OpenOffice.org Issue Tracker - Feedback Request.

The Issue you raised is currently assigned to 'Requirements' pending review, but
has not been updated within the last 3 years. Please consider re-testing with
one of the latest versions of OOo, as the problem(s) may have already been
addressed. Either use the recent stable version:
http://download.openoffice.org/index.html
or consider trying the new OOo 3 BETA (still in testing):
http://download.openoffice.org/3.0beta/
 
Please report back the outcome so this Issue may be Closed or Progressed as
necessary - otherwise it may be Resolved as Invalid in the future. You may also
wish to search for (and note) any duplicates of this Issue that may have
advanced further by checking the Issue Tracker:
http://www.openoffice.org/issues/query.cgi
 
Many thanks,
Andrew
 
Cleaning-up and Closing old Issues as part of:
~ The Grand Bug Squash, pre v3 ~
http://marketing.openoffice.org/3.0/announcementbeta.html