Since the user cannot see if his changes are done or not this seems to be a stopper.

Changed summary as this also happens if you just edit the text (f.e. by
inserting characters)

Some observations:

I can only reproduce this bug when the point edit mode is active (which it is by
default for the bugdoc.)

The VOCBitmapBuffer is involved in painting the text shapes but does not seem to
be the cause for this bug.

Here is my current hypothesis of what is happening:

When text editing starts the handles are painted around the text shape.
The handles are painted via the OverlayManager.
The OverlayManager paints not only the handles but the convex hull that encloses
the handles as well as the edited text shape.
So, when text editing starts an area covering the handles and the text shape is
saved in a bitmap.
When this overlay buffer bitmap is created then an asynchronous paint is
scheduled that will eventually paint the area of the text shape.

When the text editing is done directly after activating the edit mode of the
text shape then the overlay manager paint is triggered after the text has been
changed.

The problem with all this seems to be that the overlay is not aware of the text
changes and paints the previously created buffer with its outdated content.
Therefore it looks like the text change is undone.

An update of the overlay manager buffer bitmap is triggered only when the view
is painted.  This is not the case for simple text edits.


There are two ways to fix this:
1. Establish a notification of edit engine text changes to the overlay manager
so that the later can update its buffer bitmap.

2. Turn off the overlay mechanism during text edits.

After more investigation it looks like I was basically right.  The buffered
overlay manager does not properly update is buffer when text is edited. When the
spell checker checks the slide visible in the slide sorter and finds spelling
errors it triggers a model change which in turn leads to the overlay manager
repaint its outdated buffer.

I decided to fix this bug by turning off the overlay mechanism during text edits
because
the foundation for this was already in the code:
SdrPaintView::EndCompleteRedraw(.) already checks whether text is currently
being edited and if so, it calls SdrPaintWindow::DrawOverlay(.) with
bUseBuffer==false.  This, however, had previously no effect when an overlay
manager had already been created; buffering was not turned off.

The fix modifies the SdrPaintWindow::impCreateOverlayManager(.) method that is
called from SdrPaintWindow::DrawOverlay(.) so that the specified bUseBuffer flag
is obeyed.  When its value has changed since the last call then the current
overlay manager is destroyed and a new one is created.  The new overlay manager
is buffered/not buffered according to the bUseBuffer flag (and the result of a
call to SdrPaintView::IsBufferedOverlayAllowed()).  Two things have to be noted
regarding this exchange of overlay managers:

1) The overlay objects managed by the current overlay manager have to be moved
to the new overlay manager.  This is because their owner does not know of the
exchange and can not be informed of it.

We could run into problems with owners that remember the overlay manager at
which they added their overlay objects.  When the owners try to remove the
objects the overlay manager does not exist anymore.  This does not lead to a
crash but the overlay objects would remain active.

2) Both overlay managers need an external invlidation of their output devices
(the one to which they ultimately render their content, typically a visible
window).  The buffered overlay manager needs this to have its back buffer
properly initialized.  The unbuffered overlay manager needs it to trigger an
initial paint of the overlay objects.

This invalidation should not be necessary and be handled by the overlay managers
themselves.


Modified files are:
/svx/inc/sdrpaintwindow.hxx    rev. 1.6.210.1
/svx/inc/svx/sdr/overlay/overlaymanager.hxx    rev. 1.4.208.1
/svx/source/sdr/overlay/overlaymanager.cxx    rev. 1.6.208.1
/svx/source/svdraw/sdrpaintwindow.cxx    rev. 1l8.210.1

added aw to cc

Please verify.

Verified in CWS.

cannot verify / close, as the mentioned bugdoc is at a internal server

Tested in OOO300_m7. Closed.