Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||repaint error in table control if border is changed|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Priority:||P3||CC:||Armin.Le.Grand, drewjensen.inbox, frank.schoenheit, issues|
|Version:||OOo 2.3.1 RC1|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description andreschnabel 2007-11-24 09:40:58 UTC
This happens only on WinXP (Linux and Vista are ok). If the border of a table control is changed (e.g. from 3d look to flat) the table control will be drawn in front of all floating UI elements like the property window or floating toolbars. To reproduce just - open a writer doc, - insert a table control (enable form controls toolbar and klick on More Controls) - open property window for the table control and place it, so that it overlaps the table control - change border from 3D Look to flat -> Table control will be drawn over the property window
Comment 1 andreschnabel 2007-11-24 09:47:56 UTC
fixed typo in summary
Comment 2 Frank Schönheit 2007-11-24 22:16:38 UTC
fs->pl: Sounds like a VCL problem to me fs->aw: My second guess would be "a drawing layer problem" :)
Comment 3 philipp.lohmann 2007-11-26 09:44:42 UTC
Fascinating. Why is that table control a system window ?
Comment 4 Armin Le Grand 2007-11-26 09:58:45 UTC
AW->FS: What PL writes is exactly the problem. The Table Control is a system window even in edit mode (as You know, You did it to have it's 'Menu Bar' active :-). So there is no choice - neither from VCL nor DrawingLayer - not to paint it over the other controls. One more reason to think about my suggestion to use VCL ChildWindows for all controls even in edit mode in the future... For now, nothing can be done from my point of view.
Comment 5 philipp.lohmann 2007-11-26 10:07:29 UTC
The missing paint on the property window is certainly a vcl problem.
Comment 6 Frank Schönheit 2007-11-26 10:48:08 UTC
> The missing paint on the property window is certainly a vcl problem. Exactly. We're talking about the grid control, which is a child of the Writer's main window, being painted on top of the property browser, which is a flowing child of (the frame of?) Writer's main window.
Comment 7 Frank Schönheit 2007-11-26 10:50:06 UTC
> Fascinating. Why is that table control a system window ? Is it? Technically, it's indirectly derived from the BrowseBox (from svtools), which is a Control. Not sure which other facet tells you it's a system window?
Comment 8 Frank Schönheit 2007-11-26 11:06:24 UTC
> Fascinating. Why is that table control a system window ? Searched for any WB_SYSTEM* flag - there is none, neither at the browse box nor at its main child window (which is where all the painting happens).
Comment 9 Frank Schönheit 2008-01-31 10:31:17 UTC
*** Issue 85754 has been marked as a duplicate of this issue. ***
Comment 10 Frank Schönheit 2008-01-31 10:32:46 UTC
Given that this has a high visibility (the property browser occupies a lot of screen space, and as soon as you have a table control, and change its properties, you're likely to encounter the bug), I'd like to see this fixed for 3.0, if possible at all.
Comment 11 philipp.lohmann 2008-05-28 16:37:04 UTC
Comment 12 Rob Weir 2013-07-30 02:21:56 UTC
Reset assignee on issues not touched by assignee in more than 2000 days.