Issue 105992 - zooming documents containg (alive) form controls improperly positions the controls
Summary: zooming documents containg (alive) form controls improperly positions the con...
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: OOO320m2
Hardware: PC Windows XP
: P3 Trivial (vote)
Target Milestone: OOo 3.2
Assignee: marc.neumann
QA Contact: issues@dba
Keywords: regression
Depends on:
Blocks: 99999
  Show dependency tree
Reported: 2009-10-17 19:56 UTC by ud
Modified: 2009-11-09 10:05 UTC (History)
2 users (show)

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

Screenshot (98.18 KB, image/png)
2009-10-17 20:00 UTC, ud
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description ud 2009-10-17 19:56:50 UTC
The new zoom function for database form do not refresh the screen correct.
If i use the zoom setting by klick on (-) or (+) or by using the (strg+scroll)
the zoom works properly.
But if i click on the line, elements of the form are scrabbled and overlapped.
The form is almost unusable. I will attach an screenshot.

The database could be get from:
Comment 1 ud 2009-10-17 20:00:26 UTC
Created attachment 65421 [details]
Comment 2 drewjensen.inbox 2009-10-18 18:46:23 UTC
Confirmed w/ Win 7, DEV320m_2

It appears to happen, one way at least, when a control is (would have been)
pushed completely off the viewing area because of the zoom.

In one case (from a dozen or so tries) the controls misaligned (overlapped) when
going to an extremely small zoom factor - but could not reproduce a second time
using the specific, or other, form.

Also, it seems that when the error starts it spreads - meaning, that if one,
only one, control is about to be pushed off the display area and "moves back"
then this can affect the arrangement of controls that otherwise would have
behaved properly..

Have not checked this in stand alone documents, yet.

- I suspect, that how the controls are anchored is a factor here also, but I
can't say exactly what setting does what..yet, will work to break that down more
and will put a test file to this issue a little later.
Comment 3 marc.neumann 2009-10-19 07:24:57 UTC
reassign to the developer
Comment 4 Frank Schönheit 2009-10-20 09:04:45 UTC
That's not related to database forms, this happens in all documents containing
form controls, as long as those controls are switched to "alive" (non-design)
mode, and you zoom by large-enough steps (which usually isn't the case for mouse
wheel scrolling and the "+"/"-" in the zoom slider).

Accepting, adding "regression" keyword (this worked in, hmm, 3.1?), nominating
as 3.2 stopper.
Comment 5 Frank Schönheit 2009-10-20 09:16:29 UTC
steps to reproduce a simple version of the bug:
- open a new text document
- make the document window small enough to display, say, half of the page
- insert a form control
- switch off form design mode
- View/Zoom
- in the "Zoom & View Layout" dialog, enter "600%" as variable zoom
- close the dialog with OK
=> the whole document zooms, but the form control stays where it is, unzoomed,
   though it should have left the screen, and should have been zoomed

Manually scrolling to the document position where the control is expected to be
makes the wrong control disappear, and a correct one appear.
Comment 6 Frank Schönheit 2009-10-21 12:12:15 UTC
fixed in CWS dba32i

find more information about this CWS, like when it is available in the master
builds, in EIS, the Environment Information System:
Comment 7 Frank Schönheit 2009-10-27 22:28:09 UTC
fs->msc: please verify in CWS dba32i
Comment 8 marc.neumann 2009-10-30 10:00:12 UTC
verified in CWS dba32i

find more information about this CWS, like when it is available in the master
builds, in EIS, the Environment Information System:
Comment 9 r4zoli 2009-11-09 10:05:44 UTC
Verified in OOO320_m4.