Issue 123003 - Text invisible while editing in particular old documents
Summary: Text invisible while editing in particular old documents
Alias: None
Product: Draw
Classification: Application
Component: editing (show other issues)
Version: 4.0.0
Hardware: PC Windows 7
: P3 Normal (vote)
Target Milestone: 4.0.1
Assignee: Armin Le Grand
QA Contact: Susi
Keywords: regression
: 122921 123012 123017 (view as issue list)
Depends on:
Reported: 2013-08-10 17:41 UTC by Rainer Bielefeld
Modified: 2017-05-20 10:33 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: 4.0.0
Developer Difficulty: ---
jsc: 4.0.1_release_blocker+

Sample Document (13.45 KB, application/
2013-08-10 17:41 UTC, Rainer Bielefeld
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Rainer Bielefeld 2013-08-10 17:41:17 UTC
Created attachment 81301 [details]
Sample Document

Steps how to reproduce Reproducible with  "AOO 4.0.0 – German UI / German locale  [AOO400m3(Build:9702)  -  Rev. 1503704 2013-07-16 14:54:56 (Di, 16 Jul 2013)]" on German German WIN7 Home Premium (64bit)", Common 4.0-dev User Profile:

1. Open attached sample document from AOO Start center via File menu
2. Double click text box to get edit mode
3. Click behind first bullet before character of first list line
4. <Enter> for new line
5. <UpArrow> t get caret into first line directly behind bullet
6. Start typing
   Bug: New text sill become invisible when you stop typing for a moment.

Additional info:
a) Sample document is a reduced document created with LibreOffice, 
   no problem there
b) Was ok with AOO 3.4.1, so REGRESSION
c) Started with or before Rev 1457992
d) The problem seems limited to a particular class of my documents. Even when
   I simply copy the text box to a blank new document the problem disappears.
Comment 1 Rainer Bielefeld 2013-08-10 17:56:32 UTC
There are lots of additional editing problems in with these documents, for example selection with dragged mouse button is difficult ... impossible
Comment 2 Edwin Sharp 2013-08-10 19:23:19 UTC
As given in description.

Rev. 1503704 Debian
Comment 3 Rainer Bielefeld 2013-08-12 04:34:23 UTC
*** Issue 123012 has been marked as a duplicate of this issue. ***
Comment 4 Ariel Constenla-Haile 2013-08-12 05:17:33 UTC
This looks like duplicated of/related to Bug 122921
Comment 5 Oliver-Rainer Wittmann 2013-08-12 10:32:14 UTC
adding keyword regression according Rainer's description
Comment 6 Armin Le Grand 2013-08-29 13:30:07 UTC
ALG: The difference is that on the old stuff the frame around the activated text object keeps it's handles and keeps blinking, while for new ones the handles are taken away at edit activation and the blinking is stopped. Latter is how it should be. Checking why this happens with 'old' objects...
Comment 7 Armin Le Grand 2013-08-29 15:51:08 UTC
ALG: Comment accidentially added to #122920# adding here:

ALG: It depends currently on the DragSingles setting which is part of the user settings; this is the flag which switches when entering/leaving single point mode. The error can be reproduced with a new doc when switching to PointEditMode and then working on a text object. The test document has this flag set in the user settings.
Of course this sould be independent from PointEditMode; checking sources...

New comment:

ALG: This goes to old and dangerous stuff; it has to do with the EditEngine itself which gets for active text edit coupled with the active window; during text edit, it directly paints to that window (for repaints I already created a way to paint into another OutputDevice to get rid of the repaint flicker). Due to this direct painting into the window it collides with overlays, so no overlays are allowed during text edit. Thus, the text frame which can be seen during text edit is not part of the Overlay, but painted directly in the EditEngine/Outliner paint phase (SdrObjEditView::ImpPaintOutlinerView). BTW: This is one of the things I have on my list of necessary reworks...
To solve this, there is already code in SdrMarkView::SetMarkHandles which avoids handle/overlay object creation (see bHideHandlesWhenInTextEdit and bHideHandlesWhenOleActive), but only in the case for bFrmHdl (the case in PointEdit mode). This needs to be done in all modes, so it needs to be moved outside. An alternative is to force to bFrmHdl with TextEdit. Trying this out...
Comment 8 Armin Le Grand 2013-08-29 16:28:39 UTC
ALG: Works as expected, checked also #122142# and activated OLE. Some more checks, preparing commit...
Comment 9 Armin Le Grand 2013-08-29 16:31:26 UTC
ALG: Requesting AOO401 release blocker flag...
Comment 10 Armin Le Grand 2013-08-29 16:32:26 UTC
ALG: Comitted, done. Waiting for flag...
Comment 11 SVN Robot 2013-08-29 16:42:49 UTC
"alg" committed SVN revision 1518697 into trunk:
i123003 Corrected Handle/Overlay visualization when TextEdit is active
Comment 12 jsc 2013-08-30 08:37:10 UTC
approve showstopper request
Comment 13 SVN Robot 2013-08-30 09:10:27 UTC
"alg" committed SVN revision 1518918 into branches/AOO401:
i123003 Corrected Handle/Overlay visualization when TextEdit is active
Comment 14 Armin Le Grand 2013-08-30 09:10:49 UTC
ALG: Added to AOO401, done.
Comment 15 jsc 2013-09-03 09:15:03 UTC
set target milestone
Comment 16 Armin Le Grand 2013-09-03 10:35:13 UTC
ALG: Corrected owner
Comment 17 Armin Le Grand 2013-09-04 13:21:04 UTC
*** Issue 123017 has been marked as a duplicate of this issue. ***
Comment 18 Armin Le Grand 2013-09-04 13:21:23 UTC
*** Issue 122921 has been marked as a duplicate of this issue. ***
Comment 19 fanyuzhen 2013-09-17 10:13:01 UTC
It's verified fixed in build AOO401m4(Build:9713)  -  Rev. 1521921 with sample document attached