Issue 83921 - repaint error in table control if border is changed
Summary: repaint error in table control if border is changed
Status: CONFIRMED
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: OOo 2.3.1 RC1
Hardware: All Windows XP
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
: 85754 (view as issue list)
Depends on:
Blocks:
 
Reported: 2007-11-24 09:40 UTC by andreschnabel
Modified: 2013-08-07 15:45 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
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
target
Comment 12 Rob Weir 2013-07-30 02:21:56 UTC
Reset assignee on issues not touched by assignee in more than 2000 days.