Issue 87596

Summary: Dialog Model Width and Height not working anymore
Product: General Reporter: bmarcelly <marcelly.bernard>
Component: codeAssignee: Olaf Felka <olaf-openoffice>
Status: CLOSED FIXED QA Contact: issues@framework <issues>
Severity: Trivial    
Priority: P3 CC: Armin.Le.Grand, cno, daniel.rentz, frank.schoenheit, issues, mdxonefour, mikhail.voytenko, nesshof, oliver.brinzing
Version: OOo 2.4.0Keywords: regression
Target Milestone: 3.4.0   
Hardware: All   
OS: Windows XP   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
Bug demo : increase of width by 1 decreases height and width
none
writer doc with macro & dialog
none
half a patch none

Description bmarcelly 2008-03-29 20:37:08 UTC
With version 2.4.0, if the Width of a dialog model is changed, this decreases the 
dialog height. And the Width is decreased when changed by +1 !

Was correct in 2.3.1.
Comment 1 bmarcelly 2008-03-29 20:38:14 UTC
Created attachment 52365 [details]
Bug demo : increase of width by 1 decreases height and width
Comment 2 bmarcelly 2008-03-29 20:38:50 UTC
setting regression.
Comment 3 ab 2008-03-31 14:29:08 UTC
ab->bmarcelly: Which build did you use? Looks like 
a duplicate to #i84487. Could you please check?
Comment 4 bmarcelly 2008-03-31 17:07:23 UTC
bmarcelly -> ab
indeed, Issue 84487 is on a similar problem. But:

- Issue 84487 was created on 2.3.1 RC1 and corrected and closed, target 2.4.
  I have no problem on 2.3.1.

- Try the dialog macro in attachment DialogWidth.odt.
  It is OK in 2.3.1 ( 680m9 build 9238) : width increases at each button click
  It is buggy in 2.4 (680m12 build 9286) : width and height decrease at each button 
click.

The DialogWidth macro is oversimplified for demo. I was alerted by a user of Xray who 
found that the increase/decrease width buttons were unusable once upgraded to 2.4. 
Xray displays OK on 2.3.1 and shows the problem on 2.4.
Comment 5 cno 2008-04-01 11:26:02 UTC
can confirm, found strange effect also when changing dlg height
I'll attach example
Comment 6 cno 2008-04-01 11:27:39 UTC
Created attachment 52430 [details]
writer doc with macro & dialog
Comment 7 bmarcelly 2008-05-05 09:39:32 UTC
Just found this Issue was reassigned to me (author) without reason.
Reassigning issue to owner of selected subcomponent
Comment 8 ab 2008-06-04 07:10:59 UTC
Sorry, somehow this issue got lost in my in tray...
regression -> OOo 3.0

ab->cd: I can reproduce this in dev300 m14. As only the model's
with property is accessed by the macro, this seems to be a toolkit
problem on the first look. Do you have any idea?
Comment 9 Mathias_Bauer 2008-07-08 17:24:51 UTC
code freeze missed. adjusting target
Comment 10 bmarcelly 2008-12-05 10:33:25 UTC
Reminder : regression not yet corrected on DEV300m37 ...
Comment 11 carsten.driesner 2009-01-27 13:39:36 UTC
We are short before code freeze for OOo 3.1. As time is running out I have to
shift this issue to 3.2. Hopefully there is time to fix this issue soon.
Comment 12 Olaf Felka 2009-02-16 15:14:38 UTC
*** Issue 98805 has been marked as a duplicate of this issue. ***
Comment 13 Frank Schönheit 2009-02-18 09:46:23 UTC
Created attachment 60271 [details]
half a patch
Comment 14 Frank Schönheit 2009-02-18 09:55:28 UTC
See my comments in issue 98805 for more info on the background of this bug.

The attached file is not really a patch, but it proves we have a problem with
window decorations here.

First, the general idea is that model geometry information, denoted in
MAP_APPFONT, does not take into account window decoration, i.e. the window
border and the title bar. This makes sense, since the decoration depends on the
concrete graphical system the dialog is displayed on. Contrary, the geometry
information at a control (XWindow), denoted in pixel, does take window
decoration into account.

Now, there is a place in toolkit where control geometry is "translated" into
model geometry: UnoDialogControl::windowResized in
toolkit/source/controls/dialogcontrol.cxx. This method cares for subtracting the
window decoration. (which is what the fix for issue 84487 added)

The place where model geometry is translated into control geometry is in
UnoDialogControl::ImplSetPosSize (same file). This place currently does *not*
respect window decoration at all.

The patch adds a few lines which take the window decoration into account, in
ImplSetPosSize. This fixes both this issue here, and issue 98805.

Sadly, there's still something wrong: Dialogs now appear a little bit too large,
both when executed programmatically, and when executed from within the dialog
editor. More precise: "a little bit" too large means: it's as if the window
decoration has been added once too often ...

This is the place which I currently do not understand, and which means the
half.a.patch is, well, only half a patch :)

I'll stop investigating here for the moment - finally, Carsten, it's your issue,
isn't it? :)
Comment 15 carsten.driesner 2009-02-18 10:05:04 UTC
cd->fs: Thanks for your investigation. As this issue is targeted for 3.2 I hope
to find a solution for all scenarios. This example shows that quick fixes within
toolkit are likely to break other things.
Comment 16 carsten.driesner 2009-09-14 12:24:29 UTC
cd: I have too much issues to fix all of them for OOo 3.2.  Due to missing time
this issue must be moved to the next release OOo 3.3.
Comment 17 carsten.driesner 2010-09-08 14:45:55 UTC
cd: Root cause found and fixed. The decoration shouldn't be used to set the
window width, height. The patch from FS is a half workaround (it removes the
decoration size which was once added) but doesn't solve the root cause.

cd: The fix works correctly with both bug documents and uses the correct client
size for the dialog.
Comment 18 carsten.driesner 2010-09-13 13:27:26 UTC
cd: Unfortunately my fix has also a severe drawback. Although both bug docs now
work correctly on all tested platforms (Windows, Linux KDE/Gnome, Mac) there is
a serious problem with the dialog editor. Scrolling a dialog or changing values
via property browser lead to inconsistent model values. Debugging reveals that
the drawing layer calls setPosSize on the control during the paint method of the
Basic dialog editor. The drawing layer adds the decoration size whereas VCL
doesn't. Unfortunately the implementation of windowResized() of the
UnoDialogControl class is not able to distinguish between size changes from the
drawing layer or other parts like VCL or toolkit. 
Therefore I don't see a chance to fix this issue in a short amount of time.
Furthermore we need to discuss how drawing layer and toolkit should work together.
Comment 19 carsten.driesner 2010-09-13 13:31:56 UTC
cd: Have to set the issue to a later target. This is definitely not a
low-hanging fruit but shows problems in the interaction between toolkit and
drawing layer component. Fixing this issue needs a big amount of time to check
that no regression arise. Therefore I don't see a chance to fix the issue in the
next version either.
Comment 20 Oliver Brinzing 2010-10-12 12:34:18 UTC
.
Comment 21 daniel.rentz 2011-03-04 09:15:07 UTC
adding me to cc because this bug hinders correct implementation of VBA userform attributes
Comment 22 carsten.driesner 2011-03-07 12:54:50 UTC
cd: Started. Working again on this issue and looking for a solution which takes the drawing layer speciality into account.
Comment 23 carsten.driesner 2011-03-09 11:28:41 UTC
cd: Set to resolved.
Comment 24 carsten.driesner 2011-03-09 11:29:26 UTC
cd: Set mav on CC.
Comment 25 mikhail.voytenko 2011-03-09 15:11:23 UTC
The fix is reviewed and looks good.
Comment 26 carsten.driesner 2011-03-23 13:24:30 UTC
cd->of: Please verify. Please use both test documents for verification.
Comment 27 Olaf Felka 2011-03-24 14:36:18 UTC
OF: It looks good for me in cws fwk167.