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>
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
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.
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.
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.
(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.