Issue 75178

Created attachment 43556 [details]
Text field on layer 'Controls' invisible with 2.2RC2

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

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?

Reassigned. Agreed with cl and msc that this is not a stopper.

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.

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.

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.

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

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

Reference added.

*** Issue 76036 has been marked as a duplicate of this issue. ***

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.

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

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.

*** Issue 78536 has been marked as a duplicate of this issue. ***

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.

AW: Indeed, done, works from m218. Again: Be prepared that this will not be
supported in the future! Closing for now.

AW: Closing.