abdellahmehdi 0 Posted July 20, 2022 (edited) When execute, this error appears Edited July 20, 2022 by abdellahmehdi Share this post Link to post
Sherlock 663 Posted July 20, 2022 Check what is entered in the field labeled "né". This can not be converted to a date. I'm guessing that is a TMaskEdit. You should only try to convert its contents, when it is filled with data. By the way, this applies to all other date fields...and perhaps even more. 1 Share this post Link to post
Remy Lebeau 1436 Posted July 20, 2022 If you are converting the Text of the "né" control to a TDate/TDateTime using StrToDate(), consider using TryStrToDate() instead. That would avoid the EConvertError being raised. Just make sure you pay attention to its return value to know if the conversion was successful or not. Personally, I would use a TDateTimePicker or TDatePicker instead. For instance, TDateTimePicker as a built-in CheckBox that can be used to indicate whether a date has been entered. 2 Share this post Link to post
abdellahmehdi 0 Posted July 20, 2022 Just now, Remy Lebeau said: If you are converting the Text of the "né" control to a TDate/TDateTime using StrToDate(), consider using TryStrToDate() instead. That would avoid the EConvertError being raised. Just make sure you pay attention to its return value to know if the conversion was successful or not. Personally, I would use a TDateTimePicker or TDatePicker instead. For instance, TDateTimePicker as a built-in CheckBox that can be used to indicate whether a date has been entered. where,s the error Knowing that didn't work for me TryStrToDate Share this post Link to post
Remy Lebeau 1436 Posted July 20, 2022 (edited) 22 minutes ago, abdellahmehdi said: where,s the error You have 2 StrToDate() calls in that highlighted code (presumably more offscreen?), both are converting scGPDBDateEdit11.Text. Your earlier screenshot show the Text is ' / / ', which is obviously NOT a valid date string, which is why StrToDate() raises EConvertError. Quote Knowing that didn't work for me TryStrToDate It should work just fine, eg: if TryStrToDate(scGPDBDateEdit11.Text, mydate) then begin // use mydate as needed... end else begin // do something else... end; Though, like I said, TDateTimePicker makes a lot more sense then a TEdit for date inputs, eg: mydate := IncYear(DateTimePicker11.Date, a); ... mydate := IncDay(DatePicker11.Date, a); ... Edited July 20, 2022 by Remy Lebeau 1 Share this post Link to post
abdellahmehdi 0 Posted July 20, 2022 Just now, Remy Lebeau said: You have 2 StrToDate() calls in that highlighted code (presumably more offscreen?), both are converting scGPDBDateEdit11.Text. Your earlier screenshot show the Text is ' / / ', which is obviously NOT a valid date string, which is why StrToDate() raises EConvertError. It should work just fine, eg: if TryStrToDate(scGPDBDateEdit11.Text, mydate) then begin // use mydate as needed... end else begin // do something else... end; Thanks bro Share this post Link to post
Stano 143 Posted July 21, 2022 They convinced me very quickly not to use Try/StrToDate(). They consider it a reprehensible practice. 1 Share this post Link to post
corneliusdavid 220 Posted July 22, 2022 On 7/20/2022 at 10:38 PM, Stano said: They convinced me very quickly not to use Try/StrToDate(). They consider it a reprehensible practice. Really? Why? 1 Share this post Link to post
Stano 143 Posted July 22, 2022 Really. And they are "gentlemen" programmers. Because: the results can be surprising. How did the OP happen here. There are different date formats. For example, "1. 12. 2022". Oh, the spaces there are better features. For example EncodeDate. I do not question them and I arranged according to their recommendations. And I don't have problems anymore. 1 Share this post Link to post
corneliusdavid 220 Posted July 22, 2022 If you have the separate date parts already, I would definitely agree that EncodeDate is better. But if you're parsing a string, hoping it's in a date format, using TryStrToDate can avoid the exception, like @Remy Lebeaumentioned. But perhaps that's for a different use case than you're working with. 1 Share this post Link to post
Remy Lebeau 1436 Posted July 22, 2022 (edited) 1 hour ago, Stano said: Really. And they are "gentlemen" programmers. Because: there are better features. Yeah, like not using a TEdit for date/time input in the first place. Use a UI control that is specifically designed for date/time input (ie, TDateTimePicker, TDatePicker, TTimePicker). Same with integers, for instance (ie, TSpinEdit). Edited July 22, 2022 by Remy Lebeau 2 1 Share this post Link to post