Issue 115754 - don't position/size form control VCL windows during paint, but in a preceding step
Summary: don't position/size form control VCL windows during paint, but in a preceding...
Status: CONFIRMED
Alias: None
Product: Draw
Classification: Application
Component: code (show other issues)
Version: DEV300m94
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
: 108357 (view as issue list)
Depends on:
Blocks:
 
Reported: 2010-11-23 21:28 UTC by Frank Schönheit
Modified: 2017-05-20 11:33 UTC (History)
1 user (show)

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

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description Frank Schönheit 2010-11-23 21:28:49 UTC 
This is a follow-up of issue 115551. While investigating this issue, we realized
that it is a bad idea to position/size form control VCL windows (i.e. the VCL
window tied to a form control shape when the view is in alive mode) during Paint.

The reason is that there are scenarios where a form control might (legitimately)
be larger than the visible area of its parent window, this way completely
covering this visible area. For instance, imagine a document, containing a form
control, zoomed that much so that the control window covers the complete visible
area of the document view.
Now since the parent window is completely covered, it will never receive any
Paint events anymore, thus the position/size of the form control's VCL window
will never be adjusted, again.

So, we need a mechanism in the drawing layer which allows positioning/sizing
form control VCL windows, but which is independent from the actual Paint.
Comment 1 Frank Schönheit 2010-11-23 21:31:09 UTC 
reminder: when fixed, the preliminary for for issue 115551, namely the two lines
in ViewObjectContactOfUnoControl::createPrimitive2DSequence, should be removed,
again
Comment 2 Frank Schönheit 2010-11-23 21:48:39 UTC 
*** Issue 108357 has been marked as a duplicate of this issue. ***
Comment 3 Frank Schönheit 2010-11-23 21:50:26 UTC 
reminder: when this issue here is fixed, also revert the preliminary fix made
for issue 108325. Originally, reverting this fix was planned during issue
108375, but as we've seen, the solution proposed in issue 108375 is not as
comprehensive as the solution for this issue here will be.
Comment 4 Marcus 2017-05-20 11:33:45 UTC 
Reset assigne to the default "issues@openoffice.apache.org".