Bug 131196 - Formcontrols: Borders couldn't be set to "no border" through macros
Summary: Formcontrols: Borders couldn't be set to "no border" through macros
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
6.1.1.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Macro Borders
  Show dependency treegraph
 
Reported: 2020-03-07 08:07 UTC by Robert Großkopf
Modified: 2023-03-02 07:42 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Open the form and try to switch to "no border" by the button (12.78 KB, application/vnd.oasis.opendocument.database)
2020-03-07 08:07 UTC, Robert Großkopf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2020-03-07 08:07:26 UTC
Created attachment 158460 [details]
Open the form and try to switch to "no border" by the button

Open the attached database.
Open the form.
There are thre buttons which should switch the kind of border of all controls.

oField1.border = 0
should set "no border" but it doesn't work.

Switching between (1) - 3D and (2) - flat will work.

It is possible to set controls without border through the GUI, but it is impossible to do this through macros.

Tested with LO 6.4.1.2 on OpenSUSE 15.1 64bit rpm Linux.
It's the same buggy behavior in LO 6.1.1.2, could also be in versions before this.
Comment 1 Julien Nabet 2020-03-07 12:56:45 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this.

pb is I don't know how to find the code pointer.
"border" is present too many times in code.
Comment 2 Julien Nabet 2020-03-07 13:21:13 UTC
Mike: any idea how to find a code pointer for this kind of pb or know who may help here?
I don't know what pattern to search in Opengrok or where to put some break on gdb.
Comment 3 Mike Kaganski 2020-03-07 14:49:08 UTC
(In reply to Julien Nabet from comment #2)
> Mike: any idea how to find a code pointer for this kind of pb

Might be VCLXWindow::setProperty - look for "case BASEPROPERTY_BORDER"
Comment 4 Julien Nabet 2020-03-07 16:34:38 UTC
(In reply to Mike Kaganski from comment #3)
> (In reply to Julien Nabet from comment #2)
> > Mike: any idea how to find a code pointer for this kind of pb
> 
> Might be VCLXWindow::setProperty - look for "case BASEPROPERTY_BORDER"

Indeed, I put some traces in https://opengrok.libreoffice.org/xref/core/toolkit/source/awt/vclxwindow.cxx?r=87030862#1681
and we enter in this part.

Just for curiosity, how did you find it?
Comment 5 Julien Nabet 2020-03-07 18:39:08 UTC
Badfully I understand nothing here in toolkit part, peer etc.
VCLXWindow::setProperty is called once in design mode where it works
this same method is called three times when using macro and it doesn't work.
=> uncc myself

Hopefully some people are trying to rationalize/simplify LO code.
Comment 6 Mike Kaganski 2020-03-09 07:52:39 UTC Comment hidden (no-value)
Comment 7 Andreas Heinisch 2021-03-01 17:27:23 UTC
If I set the border property to "NOBORDER (4096)" the border disappears. Maybe there is a misunderstanding between "NONE" and "NOBORDER"?
Comment 8 QA Administrators 2023-03-02 03:25:11 UTC Comment hidden (obsolete)
Comment 9 Robert Großkopf 2023-03-02 06:57:20 UTC
Bug is still the same in LO 7.4.5.1 on OpenSUSE 15.3 64bit rpm Linux. Might be there is missing a refresh - no border won't change any pixel around a control.
Comment 10 Mike Kaganski 2023-03-02 07:42:51 UTC
(In reply to Andreas Heinisch from comment #7)
> If I set the border property to "NOBORDER (4096)" the border disappears.
> Maybe there is a misunderstanding between "NONE" and "NOBORDER"?

The description misses one important bit:
"Look at UnoControlEditModel Service documentation at https://api.libreoffice.org/docs/idl/ref/servicecom_1_1sun_1_1star_1_1awt_1_1UnoControlEditModel.html#a54d3ff280d892218d71e667f81ce99d4, and see that the three documented values for the Border property are "0: No border", "1: 3D border", and "2: simple border"".

It seems to me that Andreas could be right, suspecting the documentation issue here.

Or maybe (better) the "0: No border" should be converted to the VCL-internal "0x1000 NOBORDER" in UnoControlFormattedFieldModel::convertFastPropertyValue (and likewise for other control model services having Border property with identical allowed value sets, after testing that they indeed also have the same issue).