Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Dialog Model Width and Height not working anymore|
|Component:||code||Assignee:||Olaf Felka <olaf-openoffice>|
|Status:||CLOSED FIXED||QA Contact:||issues@framework <issues>|
|Priority:||P3||CC:||Armin.Le.Grand, cno, daniel.rentz, frank.schoenheit, issues, mdxonefour, mikhail.voytenko, nesshof, oliver.brinzing|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
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
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 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.