Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||transparent form controls do not paint their texts, if OOo uses desktop theming|
|Status:||CLOSED FIXED||QA Contact:||issues@dba <issues>|
|Target Milestone:||OOo 3.2|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
|Issue Depends on:|
Description sarotti 2009-07-17 15:37:37 UTC
I created several Form documents (odt), with a database connection. Opening a form does not show any label field. When scaling the document new (e.g. with scroll mouse) the labels will be shown correct.
Comment 3 sarotti 2009-07-17 15:47:06 UTC
Sorry, the original background is blue (jpg-file)... the fonts colour ist white so you first have to change the background colour to verify this issue.
Comment 4 marc.neumann 2009-08-17 14:39:09 UTC
confirm, set target and send to the right developer. As the report wrote you need to set the backgroundcolor of the page to something (f.e. blue)
Comment 5 Frank Schönheit 2009-09-29 11:57:25 UTC
Hmm, I have a hard time reproducing this. What I *do* see is the following: Changing the page background from "none" to a color, or an image, or from a color/image back to "None", makes the labels disappear. In those cases, as said, the labels re-appear as soon as you zoom the document, or otherwise force a repaint of the document view. However, in all cases I tried, the labels also appear when you close and re-open the document, all the time. That is, in my understanding we talk about a "one time" problem here, which only appears when you actually change the current background. This doesn't mean it is no bug, it just means that the severity might be different from what it is now. fs->sarotti: Can you confirm or falsify this? That is, do you have another scenario / example document where the labels are not visible in other situations?
Comment 6 Frank Schönheit 2009-10-07 12:32:13 UTC
re-targeting. As outlined above, in my understanding the issue is a one-time problem only, which can be worked around relatively easily. I'm open for suggestions how to reproduce the more severe version of the problem, as in the original description.
Comment 7 sarotti 2009-10-07 19:55:59 UTC
sarotti=>fs: I checked other form documents - but to be honest - these are without a background pictures. They are perfect. But IÂ´m wondering about another thing: The behavior depends on the number of labels. If only a few labels are in the form, you will not find this effect â€“ or only a few labels are not shown. The critical thing - personally for me - is the colleagues in my company are working active with this database and forms. I had a hard job to implement OO in my company (there was a hard fight with the MS fraction...) and now these people discuss about the decision using with OO as an alternative to MS office programs. To be honest - for me itÂ´s first of all a cosmetic thing. But itÂ´s a question for me personally.... as you can imagine If you can give me an alternative - e.g. a "special" reload for the form view, it will help me in the first step. The OO 2.0 version we used before did not show this problem (The database form were developed on basis of this version.
Comment 8 Frank Schönheit 2009-10-07 20:01:57 UTC
I perfectly understand that, however, please see above: I cannot reproduce the issue in the way you describe it: When I open the document, I see the labels. Only when I change the background in the form's edit mode, then the labels disappear. This itself is a bug, but one which rarely hits, so it doesn't justify the 3.x target. I believe that you see something different, but so far, I cannot reproduce your issue.
Comment 9 ud 2009-10-16 22:34:02 UTC
Created attachment 65413 [details] Hi i found a way to reproduce the problem in base. If i create an form in design view, and mark one field with STRG without lablefield and switch back to insert mode, the lablefields would not shown. After unmark the field in design view and go to insert
Comment 10 Frank Schönheit 2009-10-23 12:46:09 UTC
Heureka! What I never noticed before is that you're using the "Windows XP" desktop theme. My desktop theme is still "Windows classic" :), and the bug indeed does not happen with the classic theme. Also, this does not only apply to label fields, but to all fields. Changing summary.
Comment 11 Frank Schönheit 2009-10-23 12:47:13 UTC
Created attachment 65556 [details] document to reproduce the bug case
Comment 12 Frank Schönheit 2009-10-23 12:53:40 UTC
fs->aw: Attached is a document (i103611) which nicely shows that this is a problem of the drawing layer: - (ensure your OOo is using desktop theming) - open the database document - open the contained for for editing ("Edit" in its context menu) - mark the top-most (gray) edit field by Ctrl-clicking onto it - switch off the design view by clicking the respective button in the Form Design toolbar => the top-most left label field does not paint its text at all, and the right label in the second row paints only half of its text - switch on the design mode, again - mark the (gray) edit field in the second row by Ctrl-clicking it - switch off the design mode => now the *two* top most transparent label fields do not paint their text anymore, and the *third* transparent label field paints half of its text - now do the same marking the third edit field => the top three label fields are not painted at all, and the forth is painted half only So, this clearly is a drawing layer bug, as it depends on which shape is marked before switching the design mode. Also, it is a problem with control transparency, since the non-transparent labels in the document are not affected. Yet more, the problem does not happen if your OOo doesn't use the theming of your desktop. (For example, if your Windows XP is set up to use the "classic theme", which effectively means "no theme".)
Comment 13 Frank Schönheit 2009-10-23 12:55:28 UTC
just tried in OOo 3.1.1 - there the bug does not occur. => "regression" keyword, nominating as 3.2 stopper
Comment 14 Armin Le Grand 2009-10-23 14:07:02 UTC
AW: May have to do with the removal of the 'VCL hack for transparent child windows' since it should no longer have been necessary to fix a problem in VCL with transparent window repaint ("...this clearly is a drawing layer bug" ...?). AW->FS: Could You please try to add the block labeled 'VCL hack for transparent child windows' in svx/source/sdr/overlay/overlaymanagerbuffered.cxx which e.g. existed in OOO310/m15 into your current version at the same position and check if this removes the problem?
Comment 15 Frank Schönheit 2009-10-23 14:55:06 UTC
fs->aw: Yes, this indeed fixes the issue. Shall I commit to a CWS of mine?
Comment 16 Armin Le Grand 2009-10-23 14:58:33 UTC
AW->FS: Please do so. We will also need a F_up for VCL that this still does not work :-( I'll make a reminder...
Comment 17 Frank Schönheit 2009-10-23 21:14:05 UTC
fix committed to CWS dba32i
Comment 18 Frank Schönheit 2009-10-27 22:26:07 UTC
fs->msc: please verify in CWS dba32i
Comment 19 marc.neumann 2009-10-30 10:17:16 UTC
verified in CWS dba32i find more information about this CWS, like when it is available in the master builds, in EIS, the Environment Information System: http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fdba32i