Apache OpenOffice (AOO) Bugzilla – Issue 80752
Basic IDE: Massive repaint problems in Dialog Editor
Last modified: 2007-09-01 19:30:09 UTC
Found by Stephan Schaefer. When showing me the problem we even got a crash on his machine (Crash report sent with key word Dialog Editor). The problem occurs when the Dialog Dialog or controls are resized. To test open Dialog Editor (Tools/Macros/Organize Dialogs: [New +] Edit). Click at the border of the dialog and resize it, e.g. to the right. The frame is resized, but the Dialog itself isn't repainted. Another very strange effect: When opening the property browser afterwards and moving it also to the right over the dialog border the Dialog gets resized ! This is accompanied by further paint problems. ab->cl: Please have a look (decided by KA) Hint: Found in SRC680 m225 / OOG m1 but also occurs in earlier versions. Just tried a SRC680 m223 with same result and a m219 with the basic problem but without the additional Property Browser problem.
Added jsk to cc
The strange dialog resizing by moving a completely different dialog is not limited to the Property Browser, it also works e.g. with the Tools/Options dialog and probably with any other one.
note to self, check relation to issue 79128
MD: added keyword regression
nearly fixed this issue. The problem was that with the new drawing scheme invented by aw, controls are now painted wrong when not on the control layer. So I put all controls for the dialog editor on the control layer. Now they are painted as controls and this solves the basic paint issue for resizing the dialog. But this gave way to another error. During the new control paint, aw changes position and size of the controls (why? I dunno) but since the dialog editor is listening to such calls it again resizes the dialog accordingly wich causes a new paint that again, go figure. I solved this by adding a paint guard to the dialog editor, not processing postion and size changes during paint. This may leave some problems open, not sure. During the invinite resize session I got a clue about why the controls are not painted (only text of controls is visible) . They are actually painted but looks like they are painted on the actuall window, not the backbuffer. They are then overpainted by the backbuffer when the text gets painted. I have to follow this clue and check out toolkit now. Besides this issue is not completly fixed since there are redraw issues *sigh* when the dialog is made smaller. in that case the previous occupied area is not redrawn....
ok, after fixing issue 80543 the repaint issues are gone. fixed in basctl/source/inc/dlged.hxx (r 1.18.22.1) basctl/source/dlged/dlged.cxx (r 1.51.4.1) basctl/source/dlged/dlgedobj.cxx (r 1.51.16.1) Sure fs and aw should take a look at my reasons to introduce a repaint guard here.
verified in cws, please test
reassign to msc
verified in cws impress128
verified in OOG680_m3 -> closed