Bug Hunting Session
Bug 30873 - Field variables break with additional formats
Summary: Field variables break with additional formats
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 62106 (view as bug list)
Depends on:
Blocks: Fields
  Show dependency treegraph
 
Reported: 2010-10-14 08:25 UTC by Domen Kožar
Modified: 2019-03-19 07:41 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Domen Kožar 2010-10-14 08:25:37 UTC
Here is how to reproduce the problem:

1. Press ctrl-f2
2. Go under variables
3. Select User Field
4. Under name type "foobar", under value type 13:30
5. In right pane select additional formats, then select time, and select first formatting (13:37), click OK
6. Press insert and close the dialog

So far so good.

Now type some text and feel like inserting the same variable at some other location.

8. Ctrl-f2
9. find foobar and you will see it contains some wierd value: 0,5625 (while the real value should be 13:30)

It seems like format does not get saved at all and when the dialog is opened another time, default formatting is used (standard) which screws the value.
Comment 1 Muthu 2010-10-20 13:09:50 UTC
Re-assigning....
Comment 2 Cédric Bosdonnat 2010-10-28 08:58:11 UTC
This is related to http://qa.openoffice.org/issues/show_bug.cgi?id=59209.

IMHO, this could be an Easy hack. The code to hack is lying in:
  + the SwFldMgr::InsertFld() method at sw/source/ui/fldui/fldmgr.cxx, line 1206
  + the SwValueFieldType class will need to be extended to remember the format of the last insertion (sw/source/core/fields/usrfld.cxx)
  + the UI will need to select the format according to the one saved in the SwValueFieldType (see the tab pages implementations in sw/source/ui/fldui folder)
Comment 3 Giuseppe Castagno (aka beppec56) 2010-11-15 07:40:39 UTC
@Cédric: is there someone working on this issue?
If someone is not looking into it, I'll give it a try.
Comment 4 Cédric Bosdonnat 2010-11-16 00:22:04 UTC
(In reply to comment #3)
> @Cédric: is there someone working on this issue?
> If someone is not looking into it, I'll give it a try.

Sure, please take it ;)
Comment 5 Giuseppe Castagno (aka beppec56) 2010-11-21 08:16:11 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > @Cédric: is there someone working on this issue?
> > If someone is not looking into it, I'll give it a try.
> 
> Sure, please take it ;)

Hi Cédric, I can work continuously on this issue only in the week-ends, so it will take some time to fix it.

A few questions:

1) I added the new format variable in SwValueFieldType class, after adding
a couple of method and some other code, I discovered that the formatting
of the user variable subtype (e.g. the time formatting of the variable
'foo' in the example above) is not saved to ODT file.
That means that we can have the same format for the same user variable
subtype in an opened document; but when the document is reloaded from
persistent storage, that format is lost;  is this all right?

2) It seems that the type of the user variable subtype can be of two type only:

nsSwGetSetExpType::GSE_STRING or nsSwGetSetExpType::GSE_EXPR,
but in the code the type is checked again against UF_STRING,
so it appears we have two different constant used for the same meaning,
which is the right one?
It seems that using only nsSwGetSetExpType::GSE_STRING and similar would be better,
removing the other definition.
Or I'm missing something?

Is there somewhere a description of how the User variable should be, e.g. expression or string?
Trying to determine it from the code behavior IMHO can lead to confusion.
Comment 6 Domen Kožar 2010-11-21 08:27:00 UTC
Just a question from user perspective, will it be possible to share ODT around and keep formatting (and ideally, convert it to DOC)?
Comment 7 Giuseppe Castagno (aka beppec56) 2010-11-23 03:27:04 UTC
(In reply to comment #6)
> Just a question from user perspective, will it be possible to share ODT around
> and keep formatting (and ideally, convert it to DOC)?

Well, ATM, the fields already have the formatting attached to them in ODT files, so you can share them around.
I'm not sure how those are converted into when saving as DOC files, perhaps Cédric have some idea on the matter.

There is a difference with user fields, though.
The formatting is transferred only if there is at least an instance of them in the file, so appears from the ODT file.
That's why I asked about that on comment #5 above.
Comment 8 Domen Kožar 2010-12-05 13:53:54 UTC
Ah, okey. Glad to see progress:)

(In reply to comment #7)
> (In reply to comment #6)
> > Just a question from user perspective, will it be possible to share ODT around
> > and keep formatting (and ideally, convert it to DOC)?
> 
> Well, ATM, the fields already have the formatting attached to them in ODT
> files, so you can share them around.
> I'm not sure how those are converted into when saving as DOC files, perhaps
> Cédric have some idea on the matter.
> 
> There is a difference with user fields, though.
> The formatting is transferred only if there is at least an instance of them in
> the file, so appears from the ODT file.
> That's why I asked about that on comment #5 above.
Comment 9 Florian Reisinger 2012-05-18 08:21:25 UTC
Removed EASYHACK from summary
Comment 10 Julien Nabet 2013-08-22 04:58:02 UTC
Giuseppe/Cédric: any update here?
Comment 11 Björn Michaelsen 2013-10-04 18:47:36 UTC
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.

see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Comment 12 Cédric Bosdonnat 2014-01-20 09:00:32 UTC
Restricted my LibreOffice hacking area
Comment 13 QA Administrators 2014-10-23 17:31:48 UTC Comment hidden (obsolete)
Comment 14 Joel Madero 2015-03-21 01:50:06 UTC
Confirmed that it still exists. Updating bug to reflect findings.

Ubuntu 14.10 x64
LibreOffice 4.4.1.2
LibreOffice 3.3 (inherited from OOo - updating)


Minor - can slow down professional quality work but will not prevent it.

Low - default. 

Please do not change anything without first contacting QA. Thanks

Removing assigned person as there has been no activity in a long time. If you are still working on it please accept it again. Thanks
Comment 15 Joel Madero 2015-03-22 16:07:18 UTC
*** Bug 62106 has been marked as a duplicate of this bug. ***
Comment 16 Robinson Tryon (qubit) 2015-12-10 11:50:46 UTC Comment hidden (obsolete)
Comment 17 jani 2016-02-17 07:54:03 UTC
There are no code pointers ?
Comment 18 Akshay Deep 2016-02-17 08:07:07 UTC
Kindly review this patch submitted for this bug :)

https://gerrit.libreoffice.org/#/c/22165/
Comment 19 jani 2016-04-12 16:00:45 UTC
Akshay@ Still working on this patch (otherwise please unsaying yourself) ?
Comment 20 jani 2016-06-01 08:07:58 UTC
Putting on NEEDINFO, until code pointers are added (mandatory for easy hack)
Comment 21 jani 2016-07-06 06:14:19 UTC
see comment#2
Comment 22 jani 2016-10-25 12:44:06 UTC
Not an easyHack, after consultation (and real code pointers are missing)
Comment 23 QA Administrators 2018-05-31 02:52:40 UTC Comment hidden (obsolete)
Comment 24 Samuel Mehrbrodt (CIB) 2019-03-19 07:41:28 UTC
Remove easyhack keywords per comment 22.