Issue 75178 - Text field on layer 'Controls' invisible
Summary: Text field on layer 'Controls' invisible
Alias: None
Product: Draw
Classification: Application
Component: viewing (show other issues)
Version: OOo 2.2 RC2
Hardware: PC Windows XP
: P3 Trivial (vote)
Target Milestone: OOo 2.3
Assignee: Armin Le Grand
QA Contact: issues@graphics
Keywords: regression, release_blocker
: 76036 78536 (view as issue list)
Depends on:
Reported: 2007-03-06 17:51 UTC by Rainer Bielefeld
Modified: 2007-07-10 10:46 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Text field on layer 'Controls' invisible with 2.2RC2 (9.51 KB, application/
2007-03-06 17:53 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 2007-03-06 17:51:50 UTC
The attached document contains 3 text fields on different layers. The text field
on layer 'Controls' is visible with "2.0.2  German version WIN XP:
[680m5(Build9011)]", but invisible with "2.2.0RC2  Multilanguage/German version
WIN XP: [680m9(Build9124)]".

If you doubleclick the text field on "Controls" (you must not select that
layer), the text becomes visible.

This problem might be related to Issue 75095
Comment 1 Rainer Bielefeld 2007-03-06 17:53:17 UTC
Created attachment 43556 [details]
Text field on layer 'Controls' invisible with 2.2RC2
Comment 2 Rainer Bielefeld 2007-03-07 04:27:07 UTC
It's more serious than I thought, elements in layer 'Controls' all are
invisible. with "2.2.0RC2  Multilanguage/German version WIN XP:
[680m9(Build9124)]". Becauseto of the  assign to a specified use of 'Controls'
(Form controls will always be drawn into that layer) I now am pretty sure that
this is just the same problem as reported in Issue 75095, and I believe that the
problem will be solved with the fix for that issue.
If not, we would still have a showstopper for 2.2
Comment 3 wolframgarten 2007-03-07 08:16:06 UTC
I still have the CWS with that fix. Opening the bugdoc there does not show the
textbox. Doubleclicking brings it up but deselecting lets it vanish again.
Inserting a button makes it visible at last. Reassigned. @cl: is this fs again
and again a stopper?
Comment 4 wolframgarten 2007-03-07 09:04:42 UTC
Reassigned. Agreed with cl and msc that this is not a stopper.
Comment 5 clippka 2007-03-07 09:11:51 UTC
I don't consider this a showstopper because it only affects non control shapes
that are placed on the control layer. That is a very unlikely scenario. There is
also a workaround by assigning the shapes to another layer.

It is still a very sersious issue but for my opinion to late for 2.2.
Comment 6 Armin Le Grand 2007-03-07 11:20:31 UTC
AW: Form controls need exceptional handling (and will always need) because they
are sometimes real VCL windows (some even always, think about grid controls).
This implies that:

(a) a form control layer always exists
(b) all form controls are member of the form control layer
(c) form conrol layer can only keep form controls

With that paradigmas, documents which draw objects on form control layer are
corrupted and will need to  be correted at load time. Already talked to FS and
he agrees.
2nd thing is to disable/forbid UI actions to change layer settings for normal
objects to form controls.
Comment 7 clippka 2007-03-07 16:19:21 UTC
cl: I concur with the special handling for controls. What I don't understand is
the need for the control layer. To my understanding a layer has no affect on
paint order (except that all shapes on a layer could be hidden/make non
printable at once).

Since I would love to replace the old layer paradigma with real z-order and
maybe position changing layers, it would be nice if there is no such 'special'
layer like the control layer.
Comment 8 Armin Le Grand 2007-03-08 09:57:04 UTC
AW->CL: This is a very future-stretched and Draw/Impress centered view of
things. I share this thoughts with You for Draw/Impress, but it's one of seven
DrawingLayer users and the bug is now and needs to fixed near to the 2.2.1/2.3
timeline. The BugFix is what this task is about.

SW and SC DO paint layer-oriented today (hell, heaven, form layer), i ask myself
more why Draw/Impress did never do the necessary changes in the old days. This
would have of course given much more weight to the layer UI controls, because
their order would influence the paint order, too. Layer-oriented painting is
just not used there yet, at least not consequently because it's used for form

The simple fact is: We do not need (and cannot, see other apps) to 'replace' the
current mechanisms, we need to rework it in some aspects (of course) and can use
it for what You suggest, as it is done in SW/SC. This would also require to add
UI for layer management ASAP.

The other facts (to have form controls in the front) have to do with:
- form controls may be VCL windows
- their paint still uses the Show()/Hide()/SetParent() hack which does NOT take
care of clip regions set during paint and NOT handle transparent controls (e.g.
radio buttons) without special handling (we are working on those...)
- even in design mode, we have at least one control (grid control) that is a VCL
window in that mode, so not even in this mode can You visualize the controls as
part of a single Z-Order (with overlapping)
- Switching from life mode to design mode would potentally (for the user
surprisingly and suddenly) overpaint some controls which were in the front
before (due to their VCL window nature)

So, ATM there is no way to avoid a forms layer and to make it working.
Comment 9 wolframgarten 2007-04-03 07:58:18 UTC
Reference added.
Comment 10 wolframgarten 2007-04-03 07:58:29 UTC
*** Issue 76036 has been marked as a duplicate of this issue. ***
Comment 11 timcastle 2007-04-09 16:38:57 UTC
I too have this problem.  For some documents I have used the control layer to
place objects that must appear in front of all other layers (such as masks). 
These documents are now useless in 2.2.  I realize, by reading this thread, that
this is not the intended primary function of the control layer, however, it is
important to have layers in a drawing program that can be assigned as either in
the forground or background of other layers.
Comment 12 Armin Le Grand 2007-04-11 16:58:12 UTC
AW->timcastle: Sorry for that, but layers never supported the paint sequence for
objects. We know it's not what You expect, that's why we think about changing this.

Fact is ATM that for form controls, it was exceptionally done for this special
layer, but only as a 'hack' because of the problems with form controls and that
they are 'Windows' in live mode (some even in non-live mode) and thus are
technically unavoidable in front of other objects. It was done historically to
have no too big visible change between live and non-live form control mode (to
get closer to WYSIWIG maybe?).

Another fact is that Impress removed Layers for the last major release
completely, so the trend is going into the wrong direction from my point of view.

For the moment You unfortunately used a 'non-official' feature, sorry for Your
Comment 13 skiani 2007-05-18 18:25:17 UTC
This is really a problem we have a bunch of drawings with objects in the
controls layer that now open partly blank. Only solution is cut everything off
that layer and paste into another layer. Unfortunately this breaks glue points, ugh.
Comment 14 christian.guenther 2007-06-18 13:08:01 UTC
*** Issue 78536 has been marked as a duplicate of this issue. ***
Comment 15 Armin Le Grand 2007-06-27 11:49:26 UTC
AW: Good news: With aw046, all objects from the form control layer should be
painted again.

REMINDER: This does not mean that it is a good idea to have non-FormControl
objects on the Form-Layer at all. DO NOT DO THAT. This may be removed again in
the future for technical reasons. The FormLayer is ONLY for FormControls.
Comment 16 Armin Le Grand 2007-07-10 10:46:00 UTC
AW: Indeed, done, works from m218. Again: Be prepared that this will not be
supported in the future! Closing for now.
Comment 17 Armin Le Grand 2007-07-10 10:46:33 UTC
AW: Closing.