Bug 138387 - LO base Forms controls: default attribute, background colour, behaviour of unmaximized window
Summary: LO base Forms controls: default attribute, background colour, behaviour of un...
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
7.0.3.1 release
Hardware: x86-64 (AMD64) Linux (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-11-21 08:27 UTC by Richard Demattio
Modified: 2021-10-14 14:59 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
screenshot to topic 1 (70.84 KB, application/pdf)
2020-11-21 08:28 UTC, Richard Demattio
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Demattio 2020-11-21 08:27:29 UTC
Description:
This time I would like to request some "nice to haves" or elimination of boring behaviour:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
1.) in unmaximized forms window - editing mode:
    if you enter a group and exit, the window decreases its hight
    and becomes smaller and smaller and the controls are jumping up and down.
    Because it probably depends on the toolboxes I have in use, 
    I am going to send a screenshot as attachment
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2.) definition of "default" value in controlfields:
2.a.) if you would like to have "0" (zero) as default value,
      you first have to define for example "1" and then change to zero.
      If you try to enter "0" directly, it is interpreted as "empty" (NULL?)
2.b.) the other way round is also a problem:
      it is not possible to change the default value to empty/NULL.
      You have to delete the control and add it from scratch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3.)   Background color of controls and label fields
3.a.) it is not possible to define the background of controls to "transparent".
      This can be a nice attribute for "disabled" controls
3.b.) if you change the transparent background of a label field accidentally,
      it is not possible to change it back to transparent 

Steps to Reproduce:
1.I guess, the description is self explaining
2.
3.

Actual Results:
see description

Expected Results:
nice to have: 
ad 1) window does not change size and the controls are not jumping
ad 2) changing default values to NULL and 0 (zero) should be possible
ad 3) changing color to transparent should be possible


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
Version: 7.1.0.0.alpha1+
Build ID: 312a33b7636334f6ce3b6d1702bc5d3e45215601
CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: de-AT (en_US.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-11-17_01:31:31
Calc: threaded

Graphics:  Device-1: 
           VMware SVGA II Adapter driver: vmwgfx v: 2.18.0.0 bus ID: 00:02.0 
           chip ID: 15ad:0405 
           Display: x11 server: X.Org 1.20.8 driver: 
                    vmware unloaded: fbdev,modesetting,vesa 
           resolution: 1920x1014~60Hz 
           OpenGL: renderer: SVGA3D; build v: 2.1 Mesa 20.0.8 direct render: Yes
Comment 1 Richard Demattio 2020-11-21 08:28:13 UTC
Created attachment 167448 [details]
screenshot to topic 1
Comment 2 Robert Großkopf 2020-11-22 08:00:35 UTC
Please write down one buggy behavior or one enhancement request for one bug. If you write down more bugs the status can't be changed for one of the bugs. Every person has to look for every bug an then can't confirm if there is only one part of your whole description unconfirmed.
Comment 3 Julien Nabet 2020-11-22 08:59:36 UTC
About 3.b.) "if you change the transparent background of a label field accidentally, it is not possible to change it back to transparent "
=>You can put it back to transparent by using "Default"
Comment 4 Richard Demattio 2020-11-22 09:34:09 UTC
(In reply to Robert Großkopf from comment #2)

Sorry it's never too late to learn.
So let this ticket be for topic one - the crazy behaviour of unmaximized window.

and I will create another one for topic 2

(topic 3 is not a bug as I can see in Juliens comment 3)
Comment 5 Richard Demattio 2021-03-08 19:01:11 UTC
let's cancel this ticket, because of having three bugs described here.
Its confusing and I will create a new one for position 1, if I can reproduce it in release 7.1 or 7.2
Comment 6 Robert Großkopf 2021-10-14 14:59:00 UTC
(In reply to Richard Demattio from comment #5)
> let's cancel this ticket, because of having three bugs described here.
> Its confusing and I will create a new one for position 1, if I can reproduce
> it in release 7.1 or 7.2

So I will set this one as RESOLVED and NOTABUG