(Just a guess?)

The DateTime TextField in a Calc cell I tried to edit claims to support the service "com.sun.star.text.textfield.DateTime". 

The service reference https://api.libreoffice.org/docs/idl/ref/servicecom_1_1sun_1_1star_1_1text_1_1textfield_1_1DateTime.html, however, lists a Public Attribiute DataTimeValue of type "com.sun.star.util.DateTime", while the mentioned inspected textfield in Calc has not an attribute of that name, but one named DateTime which also is a structure of type  "com.sun.star.util.DateTime".

There is also a service "com.sun.star.presentation.textfield.DateTime" which is not marked Published, but for which the API reference refers to the same "DateTime.idl".

Might there be an internal mixup?

Hello Wolfgang,
A new major release of LibreOffice is available since this bug was reported.
Could you please try to reproduce it with the latest version of LibreOffice
from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the bug is still present in the latest version.

Just tested again with V 6.4.0.3.
Behaviour unchanged. 
I also analysed the issue to more detail modifying the code from the attached example to exclude probable errors. In specific I successfully made working copies of the TextField property and of the DateTime structure to which I made the assignments, and then assigned the changed structur to the TextField. 
In the same way as for the simple properties IsFixed a IsDate the attempted direct assignment didn't throw an error, but had no effect. 

'setProperty()' methods neither exist for the simple properties nor for the structured property.

A copy of the TextField object also was successful and offered the respective services. It accepted the wanted assignments and showed the new values as expected. The final assignment of this copy to the TextPortion results in the error messabge "This property is read-only." A method 'setTextField()' does not exist again.

This behaviour still exists in:

Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 5244f02b4da126a1361a72ae07e8c53618dc920f
CPU threads: 12; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: en-AU (en_AU); UI: en-US
Calc: threaded

However, shouldn't this be regarded as desirable behaviour? I don't think this is a bug. It looks like a feature.

The reporter noted in a macro comment that the IsFixed value changed momentarily:

          .IsFixed      = True 'Was first accepted but later set back to False.

I couldn't reproduce this. I modified the demo macro:

          .IsFixed      = True 'Was first accepted but later set back to False.
          if (.IsFixed = True) Then
            MsgBox "Changed Ok"
          Else
            MsgBox "Did not change"
          End If

It always reported no change, even with auto-recalculate turned off.

I suspect that if any of these fields could be changed then the value would be reset again at the next sheet recalculation run. This would be what I would expect to occur.

The behaviour as it is would seem to be consistent with the nature of the TextFields that Calc offers for insertion into cells. There are three:

Date:
  this is always set to today's date;

Document Title:
  set in File > Properties (or uses the basename of the file if not set);

Sheet Name:
  the name of the current spreadsheet.

These are all values that are set elsewhere in the document or the system and I wouldn't expect to be able to change them via the textfield object in the cell.

The latter two values can be programmatically set at the document or sheet level such that the cells that use those textfields would naturally inherit the new value.

If a date embedded in cell text needs to be set programmatically then that is no-doubt possible also, but the Date TextField probably shouldn't be used as the basis for that.

There was a misunderstanding.  
If I just wanted to get the behavior of Calc changed or to get a feature added, I would post an "enhancement" bug (request).  

This is a *bug report* because the actual behavior of textfield objects imo is different from how it should be regarding the *existing specifications*.  

However, I also can't see the differences as a "feature". To the contrary it is annoying and makes textfield instances (with the exception of .textfiel.URL) in Calc next to useless. Concerning DateTime the unchangeable NumberFormat is not acceptable. 

BTW: Since I don't use sheet headers/footers, I didn't test the details, but it seems that everything I reported here about SheetCell objects also holds for textfield instances there.

(Of course, I also am unhappy with the differences in the "specialized" implementations of .Text services for generic objects of different kind, but this is off topic here.)

Just tested with LibO V7.2.0.4: Everything as reported earlier. 
The "setting back to IsFixed=False" (and similar) is reported about the actual textfield of the inspected text portion, not about the instance the code below is working on.

I also tested with the modified code below (and with additional variants):

Sub lookAtDateTimeFields() REM In advance of running this Sub: Select the single cell you want to inspect.
cell = ThisComponent.CurrentSelection(0)
For Each quasiPar In cell
  For Each portion In quasiPar
    If portion.TextPortionType="TextField" Then
      tf = portion.TextField
      With tf
        If .supportsService("com.sun.star.text.TextField.DateTime") Then
          dt = .DateTime
          .IsFixed      = True 'Was first accepted but later set back to False.
          tf.IsDate = False
          dt.Day = 1
          dt.Hours = 13
          tf.NumberFormat = h_findCreateNumberFormatStyle("YYYY-MM-DD HH:MM")
REM Name and code for findCreateNumberFormatStyle() are by Andrew Pitonyak. 
          .DateTime = dt
        End If
      End With
REM An attempt to assign portion.TextFiled = tf fails ("ReadOnly").
    End If
  Next portion
Next quasiPar
End Sub

(In reply to Wolfgang Jäger from comment #6)
> There was a misunderstanding.  
> If I just wanted to get the behavior of Calc changed or to get a feature
> added, I would post an "enhancement" bug (request).  
> 
> This is a *bug report* because the actual behavior of textfield objects imo
> is different from how it should be regarding the *existing specifications*.  

I understood that you were making a bug report, not an enhancement request.

I confirmed that what you want to do is still not possible. In doing so I did not want to imply that I agree that it's a bug, so I put the question forward. Now someone else can decide.

(In reply to Xisco Faulí from comment #2)
> Hello Wolfgang,
> A new major release of LibreOffice is available since this bug was reported.
> Could you please try to reproduce it with the latest version of LibreOffice
> from https://www.libreoffice.org/download/libreoffice-fresh/ ?
> I have set the bug's status to 'NEEDINFO'. Please change it back to
> 'UNCONFIRMED' if the bug is still present in the latest version.

Xisco, I assume you want independent confirmation before setting to 'NEW'. I have confirmed ([comment 5]) that what Wolgang is trying to do is still not possible in:

Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 7b31f7428a1469fa823538fe5cf9cf36bbe2df68
CPU threads: 12; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: en-AU (en_AU); UI: en-US
Calc: threaded

I've set status to 'NEW' accordingly.

Dear Wolfgang Jäger,

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 https://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://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug