Created attachment 63604 [details]
Example for problem

Created attachment 63605 [details]
label problem view

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.

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)

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?

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.

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.

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.

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

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.

Created attachment 65556 [details]
document to reproduce the bug case

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".)

just tried in OOo 3.1.1 - there the bug does not occur. => "regression" keyword,
nominating as 3.2 stopper

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?

fs->aw: Yes, this indeed fixes the issue. Shall I commit to a CWS of mine?

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...

fix committed to CWS dba32i

fs->msc: please verify in CWS dba32i

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