How to use tDateTimePicker for BOTH date and time

[A.M. Hoornweg 144]

OK, this took me some time to figure out, but it is actually possible:

 

- Put a tDateTimePicker on your form

- Set property "Kind" to "dtkDateTime"

- Set property "Format" to "dd/MM/yyyy HH:mm:ss"       (the capitalization of MM and HH is important!)

 

-Setting the tDateTime is easy, just use property datetime.

-Use the following routine to GET the tDatetime.

 

Function ExtractDateTime(Picker:tDateTimePicker) :tDatetime;
var buf:pWideChar; LastBlank,i,len:integer;
    Text,TimePart:string;
begin
     len:=picker.GetTextLen+1;
     buf:=Stralloc(len);
     picker.GetTextBuf(buf,len);
     Text:=buf;
     strdispose(buf);

     LastBlank:=length(Text);
     for i:=length(Text) downto 1 do
     begin
       if Text[i]=' ' then
       begin
         LastBlank:=i;
         break;
       end;
     end;

     TimePart:=Copy(Text, LastBlank+1, length(Text));
     result:=picker.Date+strtotime(TimePart);
end;

 

 

 

 

 

[Remy Lebeau 1401]

5 hours ago, A.M. Hoornweg said:

- Set property "Kind" to "dtkDateTime"

That must be a new feature added in 11.0 Alexandria, because in 10.4 Sydney the only options available were still dtkDate and dtkTime.  In which case, I would expect there to be a new and easier way to get the full TDateTime value without resorting to parsing the display text manually.

Edited March 8, 2022 by Remy Lebeau

[Uwe Raabe 2058]

6 hours ago, A.M. Hoornweg said:

-Setting the tDateTime is easy, just use property datetime.

-Use the following routine to GET the tDatetime.

When do simply reading property DateTime fail?

 

And for versions below Delphi 11 it is sufficient to set Kind to dtkDate;

[A.M. Hoornweg 144]

Simply reading property "datetime" fails in Alexandria if property "kind" is set to dtkDateTime.  All manual changes in hh:mm:ss are completely ignored.

 

 

 

 

[Uwe Raabe 2058]

29 minutes ago, A.M. Hoornweg said:

Simply reading property "datetime" fails in Alexandria if property "kind" is set to dtkDateTime.  All manual changes in hh:mm:ss are completely ignored.

Well, I cannot reproduce that here. My testing scenario looks like this:

• drop a TDateTimePicker and a TButton on a plain VCL form
• set DateTimePicker1.Kind to dtkDateTime (leave Format empty for the moment)
• add a Button1Click event with the following content:   ShowMessage(FormatDateTime(DateTimePicker1.Format, DateTimePicker1.DateTime));
• run the program: Date/Time is displayed with missing seconds, but that was expected
• click the button: Date/Time is displayed with seconds
• select date and time control and edit date and time values
• click the button: new Date/Time is displayed with seconds
• the same holds true when the Format property is set as you suggested

 

[A.M. Hoornweg 144]

That's very weird. My system behaves differently and so does a colleague's computer.  The problem has been plaguing us for some time. I'll dig into this.

 

 

 

 

[Pat Foley 51]

What do the Objects look like IDE?

Design copy from 10.4 

 

// after fix

object DateTimePicker1: TDateTimePicker
  Left = 280
  Top = 32
  Width = 186
  Height = 21
  Hint = 
    'Use<> arrow keys to select time field Up/Down arrow Keys to sele' +
    'ct new field value'
  Date = 44628.000000000000000000
  Format = 'dd/MMM/yyyy hh:mm:ss'
  Time = 0.690069409720308600
  DateFormat = dfLong
  ParentShowHint = False
  ShowHint = True
  TabOrder = 5
end

 

//Fresh

object DateTimePicker2: TDateTimePicker
  Left = 64
  Top = 32
  Width = 186
  Height = 21
  Date = 44629.000000000000000000
  Time = 0.024456481478409840
  TabOrder = 6
end

[A.M. Hoornweg 144]

Duh.   It looks like we got bitten by visual form inheritance.   The tDatetimepicker is on a base tForm that is inherited from. This base form is perfectly OK but I see in an inherited DFM that "tDateTimePicker.Kind" is reverted to dtkDate.  I can't explain how this happened. 

 

 

[Remy Lebeau 1401]

9 hours ago, A.M. Hoornweg said:

Simply reading property "datetime" fails in Alexandria if property "kind" is set to dtkDateTime.

Has that been reported as a bug yet?  If not, it should be.

 

[Uwe Raabe 2058]

32 minutes ago, Remy Lebeau said:

Has that been reported as a bug yet?  If not, it should be.

Actually that works as expected. The problem seems to be a wrong configuration in a derived form. A simple test inheriting a form showed that this works, too. Must be some other reason for the problem seen. Up to now I cannot see a bug in Delphi here. Perhaps someone can reproduce?