Apache OpenOffice (AOO) Bugzilla – Issue 87596
Dialog Model Width and Height not working anymore
Last modified: 2017-05-20 10:30:41 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.
Created attachment 52365 [details] Bug demo : increase of width by 1 decreases height and width
setting regression.
ab->bmarcelly: Which build did you use? Looks like a duplicate to #i84487. Could you please check?
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.
can confirm, found strange effect also when changing dlg height I'll attach example
Created attachment 52430 [details] writer doc with macro & dialog
Just found this Issue was reassigned to me (author) without reason. Reassigning issue to owner of selected subcomponent
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?
code freeze missed. adjusting target
Reminder : regression not yet corrected on DEV300m37 ...
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.
*** Issue 98805 has been marked as a duplicate of this issue. ***
Created attachment 60271 [details] half a patch
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? :)
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.
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.
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.
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.
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.
.
adding me to cc because this bug hinders correct implementation of VBA userform attributes
cd: Started. Working again on this issue and looking for a solution which takes the drawing layer speciality into account.
cd: Set to resolved.
cd: Set mav on CC.
The fix is reviewed and looks good.
cd->of: Please verify. Please use both test documents for verification.
OF: It looks good for me in cws fwk167.