Apache OpenOffice (AOO) Bugzilla – Issue 93318
changes made to a form control's appearance are not show anymore, until you move/resize the form control
Last modified: 2009-01-19 10:00:28 UTC
- open the attached document - double-click the contained control to open the property browser - change the background color to some arbitrary color => the change is not reflected in the document/control - move or resize the control => the control now has the background color it should have This happens for all appearance-related properties, not only the background color. Seems that the mechanism which invalidates the portions of the document window occupied by the control, whenever a control property changes, does not work anymore.
Created attachment 56134 [details] document to reproduce the bug case
regression between m29 and m39 => keyword, target
fs->aw: The code which normally triggers the update (more precise, the invalidation) is in ViewObjectContactOfUnoControl_Impl::propertyChange: There, a call to ObjectContact::InvalidatePartOfView is made when a property of a control changes in design mode. This code fragment is still called, but does not seem to work anymore since m30.
AW: First check: No ActionChanged() at the VC is triggered (what is an error).
AW: problem is that the ControlPrimitive2D::operator== does not detect XControlModel changes which includes properties. There are three ways to fix that: (1) Use a copy of the properties from XControlModel for ControlPrimitive2D, not the XControlModel itself. Thus, the changes would get recognized (2) use a propertyChangeListener at the ControlPrimitive2D which reacts on property changes at the XControlModel and e.g. remembers change in a local bool to return false at the next comparison (3) At the tooling providing the primitives (the VOCs and VCs), where the comparison is needed, use the derived classes for FormControls (which exist) to do the extra test on property change. This may also result in flushing the cached primitives at the VOC/VC on property change. That would guarantee to get a fresh created primitive sequence on next request (1) is too expensive, (2) works (tried that and committed as SVN tag 262201 to have the code on demand). Removed again since this does not meet the purpose of a primitive. The primitive represents the graphical information of a visualizable object at the time the primitive was created, nothing more. I imlemented and tested (3). Works well. committed. Done.
*** Issue 95489 has been marked as a duplicate of this issue. ***
AW->WG: Please review as described in the task. Maybe FS wants to check, too.
looks good in CWS aw058, thanks.
*** Issue 96452 has been marked as a duplicate of this issue. ***
Tested in m38. Closed.