Bug 135287 - The Time Control no longer supports 12-hour times through TimeFormat
Summary: The Time Control no longer supports 12-hour times through TimeFormat
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
6.2.5.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-29 18:47 UTC by atemple
Modified: 2021-02-04 15:53 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
An ewxample tghat shows that TimeForamt does not work on my Libre installation (60.68 KB, application/vnd.oasis.opendocument.text)
2020-08-03 22:02 UTC, atemple
Details

Note You need to log in before you can comment on or make changes to this bug.
Description atemple 2020-07-29 18:47:38 UTC
The Problem: The Time Control no longer supports 12-hour times, even if you set TimeFormat to 2 (12 Hour - Short) through BASIC or directly in the dialog itself. (i.e. making that the default format.)

What Actually Happens: Even though the Time Control accepts changes to the TimeFormat value, it does not act on that change. It always uses 24 Hour time -- it never displays am/pm at all. If you use the Up Arrow, with the cursor in the hour part of the Time Control, you'll see that after 12:00 it goes to 13:00, 14:00, etc. A user can ignore what he sees in the Time Control display, and type out a full am/pm time such as "1:30 pm" and the Time Control does accept that and converts it to the correct 24 Hour time, namely 13:30.

To replicate this behavior, I've supplied a small BASIC sub, GetMyTime(), that accesses a very simple dialog that has only a Time Control (TimeField1) and an OK and Cancel button. (You can make this yourself, or you can import the dialog file I exported. See below. I call this from Writer.)

In my Sub, you'll see the line:

   If isNumeric(oCtl.getTime()) Then

Around version 4.1.1.2 of Libre, they made the switch to using a structure for the Time instead of the Long that has been used since the early days with OpenOffice. (See Bug 68751 - Date Controls changed in Basic.) If I were to make a guess, I'd look at the point when this change was made to see if that's where the new problem with TimeFormat was created.

This is a particularly nasty problem for me. I'm developing a Libre Template that creates a Diary / Day Planner for Writer, and the Day Planner's Appointment Time column uses either 12 or 24 hour time format. But as this is initially being created only for English-speaking countries, 12 Hour am/pm time is really the only option that users will actually want. As it is, I'll have to add some code to test for Libre version and to use a MSgBox() to explain to users with the inoperable TimeFormat, that they'll just have to type in the full am/pm time that they want. I hope this can be fixed soon.

Last Thought: The code and dialog below work properly in OpenOffice 4.1.6.


Sub GetMyTime()

Dim oCtl, Dlg As Object
Dim LTime As Long
Dim PlannerHour, PlannerMinutes As Integer

   DialogLibraries.LoadLibrary("Standard")
   Dlg = CreateUnoDialog(DialogLibraries.Standard.TimeDialog)

   oCtl = Dlg.getControl("TimeField1") ' get the TimeField control
   oCtl.Model.TimeFormat = 2
   MsgBox("TimeFormat is:" & oCtl.Model.TimeFormat)

StartOver:

   ' Here we would want to set up those things as required
   
   If Dlg.Execute() = 0 Then ' Now we can execute the Dialog and allow the user to change things
      goto Leave ' User Cancelled the Dialog
   End If

   ' Get the Time the user has chosen
   oCtl = Dlg.getControl("TimeField1") ' get the TimeField control
   If oCtl.isEmpty() Then
      MsgBox("You must provide a Time for the Appointment", 16, "GetMyTime")
      goto StartOver
   End If
   
   If isNumeric(oCtl.getTime()) Then
      LTime = oCtl.getTime()  ' OpenOffice and early Libre stores Time as a Long
      PlannerHour = LTime / 1000000 ' The hour part of the long time
      PlannerMinutes = LTime / 10000 MOD 100 '  The minute part of the long time
   Else
      PlannerHour = oCtl.Time.Hours ' Later Libre stores time as a structure
      PlannerMinutes = oCtl.Time.Minutes
   End If

   MsgBox("Time is: " & PlannerHour & ":" & PlannerMinutes)

    Leave:
      Dlg.dispose()
           
End Sub




<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE dlg:window PUBLIC "-//OpenOffice.org//DTD OfficeDocument 1.0//EN" "dialog.dtd">
<dlg:window xmlns:dlg="http://openoffice.org/2000/dialog" xmlns:script="http://openoffice.org/2000/script" dlg:id="TimeDialog" dlg:left="136" dlg:top="106" dlg:width="62" dlg:height="69" dlg:closeable="true" dlg:moveable="true">
 <dlg:styles>
  <dlg:style dlg:style-id="0" dlg:font-height="12"/>
  <dlg:style dlg:style-id="1" dlg:font-height="10"/>
 </dlg:styles>
 <dlg:bulletinboard>
  <dlg:text dlg:style-id="0" dlg:id="Label1" dlg:tab-index="0" dlg:left="6" dlg:top="2" dlg:width="21" dlg:height="15" dlg:value="Time:"/>
  <dlg:timefield dlg:id="TimeField1" dlg:tab-index="1" dlg:left="6" dlg:top="18" dlg:width="49" dlg:height="19" dlg:printable="false" dlg:tag="This is some additionla information" dlg:help-text="Appointment Time" dlg:hide-inactive-selection="false" dlg:strict-format="true" dlg:time-format="12h_short" dlg:value="9000000"/>
  <dlg:button dlg:style-id="1" dlg:id="CommandButton1" dlg:tab-index="2" dlg:left="35" dlg:top="44" dlg:width="20" dlg:height="15" dlg:value="OK" dlg:button-type="ok"/>
  <dlg:button dlg:id="CommandButton2" dlg:tab-index="3" dlg:left="7" dlg:top="44" dlg:width="24" dlg:height="15" dlg:value="Cancel" dlg:button-type="cancel"/>
 </dlg:bulletinboard>
</dlg:window>
Comment 1 raal 2020-08-01 06:09:57 UTC
Hello,

Thank you for filing the bug. Please send us a sample document, as this makes it easier for us to verify the bug. 
I have set the bug's status to 'NEEDINFO', so please do change it back to 'UNCONFIRMED' once you have attached a document.
(Please note that the attachment will be public, remove any sensitive information before attaching it.)
How can I eliminate confidential data from a sample document?
https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F
Thank you
Comment 2 atemple 2020-08-03 22:02:03 UTC
Created attachment 163913 [details]
An ewxample tghat shows that TimeForamt does not work on my Libre installation

I've added a few images of what's happening on my machine to better illustrate the problem. I hope that helps.
Comment 3 Xisco Faulí 2020-08-05 14:02:32 UTC
Not reproducible in

Version: 7.1.0.0.alpha0+
Build ID: 76c40b82e6a44539cd43f326c00246e759449571
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Using the up arrow goes from 12 to 1 and vice versa.

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.
Comment 4 atemple 2020-08-06 00:48:35 UTC
I installed the latest version of Libre, 7.0.0, and the bug does not appear using it. But I still have the problem with 6.2.5.2. So is it an actual bug that exits in previous versions? Or is it a problem with my installation. (I have Libre on two machines, a Win8 and a Win10, so it seems unlikely to be an installation problem affecting two machines with two versions of Windows.)

Can anyone with version 6.2 to 6.4 test this out for me? After all, if I decide to release my Template to the public, I'll have to deal with this situation if it is indeed a real bug.


Also, as I had Libre 7.0 installed, I tested the previous bug I found, bug #130888 ---  Basic is Faulty in creating / deleting User Defined Properties. I find that this bug still exists in Libre 7.0.


In the attached example file, I also mentioned another problem that I was having and I described it as:

On a dialog I have a couple of options and a listbox. But I don't want the listbox to be shown unless a particular option is selected. I have the typical code that is called when the option is selected and the code then makes the listbox visible. For the other options, the listbox is made invisible. But here is the strange thing: I cannot declare the listbox as not visible from the start. If I do that, my BASIC code simply cannot make it visible – it remains invisible permanently. So to get around this, I have to first declare the listbox as visible, then make in invisible before I Execute() the dialog. Only then can my BASIC Code actually toggle it between visible and invisible.

This problem does not appear in Libre 7.0. But it does appear to be a bug in versions before 7.0. Should I create another example file of this problem and post another new bug report for it? I have a workaround for it, but I need to know whether it's a true bug for earlier versions of Libre.


Finally, I found a new bug in Libre today, one that affects 7.0 too. I'll try to post it tomorrow.
Comment 5 Buovjaga 2021-02-04 15:53:49 UTC
(In reply to atemple from comment #4)
> I installed the latest version of Libre, 7.0.0, and the bug does not appear
> using it. But I still have the problem with 6.2.5.2. So is it an actual bug
> that exits in previous versions? Or is it a problem with my installation. (I
> have Libre on two machines, a Win8 and a Win10, so it seems unlikely to be
> an installation problem affecting two machines with two versions of Windows.)

Then let's close this as worksforme.