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.
Re-assigning....
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)
@Cédric: is there someone working on this issue? If someone is not looking into it, I'll give it a try.
(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 ;)
(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.
Just a question from user perspective, will it be possible to share ODT around and keep formatting (and ideally, convert it to DOC)?
(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.
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.
Removed EASYHACK from summary
Giuseppe/Cédric: any update here?
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
Restricted my LibreOffice hacking area
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
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
*** Bug 62106 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (easyHack)
There are no code pointers ?
Kindly review this patch submitted for this bug :) https://gerrit.libreoffice.org/#/c/22165/
Akshay@ Still working on this patch (otherwise please unsaying yourself) ?
Putting on NEEDINFO, until code pointers are added (mandatory for easy hack)
see comment#2
Not an easyHack, after consultation (and real code pointers are missing)
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Remove easyhack keywords per comment 22.
Created attachment 157102 [details] Test document with User Fields and date and time formats Maybe this was never a bug -- if it was possible to assign formats to inserted fields at the time of the original report. In the described procedure, no mention is made of whether any formatting was applied to the newly inserted variables. If care is taken to format as Time -- then everything appears as it should. The "weird" number is simply the numerical value for 13:30. The attached document will demonstrate. Some remaining strange behaviors are mentioned at the end of the attached document. Maybe others can evaluate if they give some motivation for a new bug report. The present examples were tested with 6.5.0.0.alpha and 6.3.4.2 (though 6.3.4.2 had a problem with inserting time formatted variables), which will be reported in another bug.
Modified the summary to better reflect the content of the original report.
(In reply to sdc.blanco from comment #25) > Maybe this was never a bug So let's resolve it as NAB. > Some remaining strange behaviors are mentioned at the end... Switching the document language doesn't update the fields and a time value of 0,5 is invalid for English where dots are used. But I don't think we have to take care as time and date variables have dedicated fields that are updated properly on a language change.