Created attachment 45811 [details] screenshot of Calc UI problem (red rectangle, that remains unpainted) in Calc on windows, toolbar item "Name box" is incorrectly painted. It painted not fully and around in remains some unpainted arrea. To reproduce this start Calc, then minimize and maximize it. On top left field, containging A1, remains some background from window behind it. In attachment is screenshot. I have placed red rectangle on screen and then maximized Calc. Around field with A1 appears red rectangle. Produced on Windows XP with LibreOffice 3.3.2
There is a general repainting issue that I've been observing, though I'm not sure if this is limited to Calc, or applicable to all apps. Do you see this only in Calc, or in Writer, Impress, Draw etc as well?
I can find this problem only in Calc and only on Windows
NOT reproducible with "LibreOffice 3.4.3 RC2 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:302)]", LibreOffice Portable 3.3.3 - WIN7 Home Premium (64bit) German UI [OOO330m19 (Build:301 Tag 3.3.3.1)]" pr any other of my LibO versions. My PC: 64 bit AMD Phenom II X4 955 Processor 3.2 GHz, 4GB RAM, Graphic Card: NVIDIA GeForce GT 430 @sasha: Still a problem with the current versions? Any idea whether a setting or anything else might cause the problem?
Indeed, it is not reproducible. I can reproduce it only in one computer-room and only under Guest. It my be because of corrupted Windows. I think this bug my closed as invalid because not reproducible.
Closing due to comment before. Please feel free to reopen this Bug if you find evidence that we have an independent issue here.
Paint problem occurs with us as well (see attachment of screenshot). I have also had report of paint-problem with writer (no screen shot available_, which occurred while copy-pasting; the text to be overwritten was only partially removed. Scrolling up/down caused the screen to be properly repainted again). I think/fear this is a general repainting issue, which is difficult to reproduce. version: 3.4.3, O/S Windows XP I cannot confirm that is does not occur with Linux, as it did occur a lot in the past (with OOo) and I got so used to it, that I ignored the phenomenom. Should I observe it, I will mention it.
Created attachment 54665 [details] repaint problem, screenshot, see rows 81/82 see my comment of today
@Winfried Donkers Your test 3.4.3 is outdated, please do not reopen reports without check whether your problem still exists in current stable version. What are your results with 3.4.4? I can't see any relation of your problem (document contents repaint problem) with original report problem (UI element without frame). May be you should file a separate bug for this! The WRITER problem you mention is known, I am sure that we have a report for that, but I can not find it. Can you help Please - attach a sample document - contribute a step by step instruction how to reproduce the problem - describe what your problem is, your screenshot shows many artifacts. "Top of second line text in A64 cropped"?
(In reply to comment #8) @Rainer > Your test 3.4.3 is outdated, please do not reopen reports without check whether > your problem still exists in current stable version. What are your results with > 3.4.4? I have asked the user who reported the issue (we're a company) to update to 3.4.4 and send me a new screen dump. > I can't see any relation of your problem (document contents repaint problem) > with original report problem (UI element without frame). May be you should file > a separate bug for this! My reopening was triggered by your comment#5; as I had noticed this behaviour in multiple instances (but was not yet familiar with bug reporting) I suspect it be be a general issue, as mentioned in comment#1. I'm quite happy to file a new bug, I was just trying to avoid duplicates ;) > Can you help Please > - attach a sample document > - contribute a step by step instruction how to reproduce the problem > - describe what your problem is, your screenshot shows many artifacts. "Top > of second line text in A64 cropped"? I will help as much as I can (including picking up easyhacks), no problem. I have already asked if the user that reported to me can reproduce the problem and provide me with the calc-document. About the attached screenshot: I probably was not clear with my reference in the attachment title, but the problem can be seen in row 81/82, where the merged cells have their text. The text is 'cropped', and this was solved by zooming up/down (or vice versa). I will provide additional information when I receive it and file this as a new bug when you prefer this.
Created attachment 54672 [details] paint of merged cells is distorted open file, scroll to row 125/126 or 80/81 and look at the text in cols A, G, H, L. zoom/unzoom produces a correct repaint. the problem seems not to be related to one zoom percentage (it can occur at 90% and also at 100%) the problem can be reproduced with 3.4.3 and 3.4.4 (Windows) and on master (Linux build). INFO COMPLETE
I found a way to reproduce the problem with a new calc document: -fill cell c3 with 'abc' -fill cell c4 with 'def' -select both cells and merge them (choose to add the contents of c4 to the merged cell) - the merged cell contains distorted text (some times compressed vertically, sometimes italic, sometimes clipped, sometimes different font size) - scrolling up/down causes a proper repaint Done on 3.4.4 (Windows) and on master (Linux. It was easier to reproduce with Windows than it was with Linux.
I reproduced steps from comment 11 on Fedora 64 bit LOdev 3.5.0 (build 13 December) Cell becomes corrupted just after merging. After scrolling all renders correct. In version 3.3.4 was the same. Therefore it is not regression.
see comments 9 to 12
Cannot reproduce the problem with version 3.5.2 (Windows XP), nor on master (openSUSE 11.4)
Thanks for additional testing I also can not reproduce this bug in 3.5.2 on Fedora 64 bit Changing status to WorksForMe