Bug 30873

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