Bug 30873

Summary: Field variables break with additional formats
Product: LibreOffice Reporter: Domen Kožar <domen>
Component: LibreofficeAssignee: Giuseppe Castagno (aka beppec56) <giuseppe.castagno>
Status: NEW --- QA Contact:
Severity: normal    
Priority: medium CC: giuseppe.castagno, libreoffice, serval2412
Version: unspecified   
Hardware: x86 (IA32)   
OS: Windows (All)   
Whiteboard: EasyHack
i915 platform: i915 features:

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
Please read this message in its entirety before responding.

Your bug was confirmed at least 1 year ago and has not had any activity on it for over a year. Your bug is still set to NEW which means that it is open and confirmed. It would be nice to have the bug confirmed on a newer version than the version reported in the original report to know that the bug is still present -- sometimes a bug is inadvertently fixed over time and just never closed.

If you have time please do the following:
1) Test to see if the bug is still present on a currently supported version of LibreOffice (preferably 4.2 or newer).
2) If it is present please leave a comment telling us what version of LibreOffice and your operating system.
3) If it is NOT present please set the bug to RESOLVED-WORKSFORME and leave a short comment telling us your version and Operating System

Please DO NOT
1) Update the version field
2) Reply via email (please reply directly on the bug tracker)
3) Set the bug to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 
LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link:
https://wiki.documentfoundation.org/QA/BugTriage

There are also other ways to get involved including with marketing, UX, documentation, and of course developing -  http://www.libreoffice.org/get-help/mailing-lists/. 

Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.