The concept of control stacking order seems to be completely broken in LibreOffice 3.4.4. You can right-click a control and select Arrange->"Bring to Front", as you can with any object, but it does not seem to have any effect. By judicious use of cut and paste to change the order in which the objects were placed on a form, you can get one control to be visible over top of another control. However, once the form is "run" (design-mode turned off), the control that was on top in design mode is now on the bottom when the form is run. And as each control is used, it will appear on top of all others.
in 3.5.0beta2 the to front/background does work, but the activated control will still be brought to front in live mode (well, rendered on top, when you switch to another window and back, it will be restored to its original position). Having said all this: What it the point in having overlapping form-controls? I cannot see a real reason for it. Please provide a sample where overlapping / stacked controls are necessary.
Created attachment 54949 [details] Screenshot illustrating two examples of the usefullness of stacking controls Is the request for information in order to assign an importance/priority to the bug? I ask because the question sounds like what is being debated is whether or not the feature should be part of LO in the first place. Anyways, here is the case for working control stacking: Background: Screen real estate for forms that have complex information can be very much at a premium. This is especially the case if the form has aesthetics as a design consideration, where visual elements take up some of that valuable real estate. In many cases, squeezing controls closely together can be a challenge if stacking order is not honoured. In other cases, adding in aesthetic elements can be impossible without correct stacking order. Attached to this comment is a screen shot of a Pathfinder RPG spell database form that illustrates two instances of where failed stacking order impedes a form's design goals: Situation 1, Label field impinging on data field borders It is difficult at times to get the text of a label field as close as one would like to the data field it is labelling without the border of the label field impinging on the data field. You will notice in the area labelled "Situation 1" that the label is overlapping the top of the text box. Even using the vertical alignment setting in a label doesn't always help, depending on the font selected. Fonts with deep descenders (like the underlined label on the scroll) cause more of a problem and I ended up not being able to use the font I wanted because I could not effectively set the stacking order so that the text boxes were and stayed on top. Which makes for very ugly looking text boxes when their borders are overwritten by labels. Situation 2, Cannot put visual elements on top of controls, even when the visual elements are themselves a control. In order to save some space labelling, and to make it (in my opinion) visually more appealing, I decided to label some of the text boxes with partially transparent labels. I quickly noticed that it is absolutely impossible for the stacking order of any non-control element to make it appear over top of a control. This, I believe, is a design issue and will be addressed by a feature request. However, since using normal Draw-style text boxes for this was out of the question, I switched to an image control. I created my partially transparent image with no problem, but even with an image control I still could not get the image to reliably stay on top. It is displayed on top in the attached screen shot, but will disappear underneath if any one of dozens of cases. There are two detailed situations. In reality, though, there are a myriad of cases where stacking order is important for form element. Whether it's something as simple as reducing the time it takes to develop by not needing to bother to be picky about where label, checkbox, radio button, etc borders end (a separate issue from not being able to get labels as close as one would like to other elements), to using stacking order as a method of dynamic control selection, to overlaying buttons or controls over unused areas of other controls to save space. It's an important feature and I cannot think of any other form design software that omits it.
Incidentally, the stacking order for table controls in 4.4.x does not work at all, in any circumstance. No other control will ever appear in front of a table control.
Adding self to CC if not already on
Kurt: any update with recent LO version? Last ones are 4.3.6 and 4.4.1. Also, could you provide a simple file or explain shortly how to reproduce the problem if you still reproduce this? Please be concise since there are a lot of bugs to deal with.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team This NEEDINFO message was generated on: 2015-10-14
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team This INVALID Message was generated on: 2016-05-09