Bug 112214 - BASE, Form Editor: changing width or height of a control does not set save status to changed, thus no prompt for saving is triggered
Summary: BASE, Form Editor: changing width or height of a control does not set save st...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.3.4.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-09-04 15:02 UTC by Gerhard Weydt
Modified: 2023-10-04 05:52 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Attachments
Test doc to show the bug (11.09 KB, application/vnd.sun.xml.base)
2021-10-03 23:03 UTC, Gerhard Weydt 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Gerhard Weydt 2017-09-04 15:02:11 UTC 
Normally, if you change an attribute in a form using the control properties dialog box, the save icon will change its appearance as soon as you click into another attribute, adding the green "star" indicating that there has been a change.
This does not happen for the width and height fields.
As a consequence, there is no prompt to save the changes when the form document is closed, and the change is lost.
I have tested this with a text box, a formatted field and an Image control. In my tests I have found no other attribute whith the same behaviour as for these two fields.
The bug may be older than it seems: in 5.2 all seems to work properly, but this may be due to the fact, that the Save icon already shows the green star when opening the form document for editing, prompting to save the document even though you changed nothing. Thus the bug, if already present, would have been hidden.
Comment 1 Andreas Säger 2017-09-05 17:49:53 UTC 
+1 when using the properties dialog with a stand-alone document.
Works as expected with the mouse.

Caveat: editing an embedded database form in design mode, the form document is always dirty (modified) even when you did not change anything.
Comment 2 Gerhard Weydt 2017-09-05 19:29:58 UTC 
To avoid misunderstandings I wish to make my statement more precise.

It seems that the fact that the form document is "dirty (modified)", as Andreas said, i.e. it is flagged as modified when looking at the save symbol, is somewhat dependent on the version and/or the operating system: it does not appear for me with Windows 10 & LibO 5.3.4.2, but it does appear, as I am told, for LO 5.4.1.2, with OpenSUSE 64bit, and obviously also for Andreas.
But this is not crucial: Simply save the form document, if the flag appears after opening it for editing, and then start the operation as described.

Mark well: You can save the document, using the save symbol as well as the menu entry, and the change is saved. The problem is that the flag is not set and therefore no prompt appears when closing the document.

A second point I wish to make clear: the flag appears if you change width or height using the mouse; the wrong behaviour only happens when using the dialog fields for width or height.

Another point, not connected with this bug, but important for the handling: In order to make a change in most dialog fields effective (a selection of a list box entry works differently, for example), you have to click elsewhere: into another field or outside of the dialog, to fire the event that sets the flag. I described this a bit more detailed in Comment #15 to Bug 103575.
Comment 3 Robert Großkopf 2017-09-06 16:06:14 UTC 
Could confirm this buggy behavior. Changing of height and width of any field in a form by the properties of the control doesn't set the form to modified. Works when changing with mouse, fails with keyboard.
Comment 4 QA Administrators 2018-09-08 02:41:20 UTC Comment hidden (obsolete)
Comment 5 Gerhard Weydt 2018-09-08 19:02:15 UTC 
The problem ist still present in

Version: 6.2.0.0.alpha0+ (x64)
Build ID: 7119184f4b5441600f7b3eae7ec6771c094bbb7f
CPU threads: 4; OS: Windows 10.0; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-07-23_05:38:07
Locale: de-DE (de_DE); Calc: CL
Comment 6 QA Administrators 2019-09-09 05:30:32 UTC Comment hidden (obsolete)
Comment 7 Gerhard Weydt 2019-10-01 14:47:00 UTC 
The problem ist still present in

Version: 6.3.1.2 (x64)
Build-ID: b79626edf0065ac373bd1df5c28bd630b4424273
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: threaded
Comment 8 QA Administrators 2021-10-01 03:51:07 UTC Comment hidden (obsolete)
Comment 9 Gerhard Weydt 2021-10-03 23:03:09 UTC 
Created attachment 175484 [details]
Test doc to show the bug

I've added a very simple test document now to test the buggy behaviour.

The bug persists in
Version: 7.2.2.1 (x64) / LibreOffice Community
Build ID: 0e408af0b27894d652a87aa5f21fe17bf058124c
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: threaded

And here is the description of the steps to reproduce it:
- Open the test document
- Open the only form "Tabelle 1" for editing
- As has been remarked before, the document will be automatically set to "changed" state, which will obscure the effect to be shown; hence save the form document.
- Right-click the field with label "only field" and choose "Control Options"
- Change width or Height fields and click into another field: the Save icon won't change state.
- Then change another attribute, e. g. PositionX, and click into another field: the Save icon will change state.

Expected behaviour is that the Save icon will change state also when width or height are changed.
Comment 10 QA Administrators 2023-10-04 03:18:10 UTC Comment hidden (obsolete)
Comment 11 Robert Großkopf 2023-10-04 05:52:59 UTC 
Bug still exists in LO 7.6.2.1 on OpenSUSE 15.4 64bit rpm Linux.