So if Date is departed in 2019r2, what use is ParseDate if it can’t accept a DateTime object?
I release DateTime has DateTime.FromString which is great, but … ParseDate doesn’t show as deprecated in the IDE as other objects are now showing.
http://documentation.xojo.com/api/data_types/datetime.html#datetime-fromstring
Oops. Too fast. I missed you realized the existence of the new method.
Yes, I know. I posted that method. that’s not my question.
You could create your own global function emulating it using DateTime.FromString for a fast substitute.
Ugh, so it is - except I think there’s a bug.
Look at this method signature for DateTime.FromString (from the link you posted)
DateTime.FromString(dateValue As String, locale As Locale = Nil, timeZone as TimeZone = Nil) As DateTime
The documentation says it returns a Date object, but it returns DateTime.
Thanks Christian.
I’m considering MBS for next year. I’ve spent all I can spend on XoJo and related plugins and such for this year.
I think there are a small handful of newly deprecated items that are not currently highlighted properly in the 2019r2 IDE. I reported one <https://xojo.com/issue/57751>
As well, there have been a few documentation mistakes and things not yet updated for API 2.0. I suggest you submit a Feedback report when you find them, so they can be fixed or updated.
I hope that helps.
thanks Scott
Basically the whole date class is deprecated with API 2.0. So in a way it makes sense that ParseDate does not show as deprecated because the class itself should. (I know this point of view is debatable.)
Why… I wish I new why.
IMO Date was not broken and in their blog post, they talked about doing minimal harm…
I have piles and piles of refactoring to do.
You dont have to, at least not now and not in the nearer future. API 1.0 will stay for a long time.
Date is only deprecated because DateTime is its API 2.0 replacement. It might become necessary to change your date code once supported platforms use API 2.0 too with their controls, but currently that is not the case.
I could be convinced to ignore it of not for all the compiler warnings. I’ve looked for an option to disable warnings for deprecated code… don’t see them.
Under the “Project” menu of the IDE, click on “Analysis Warnings…”.
In the new window, I think if you uncheck the second item in the list “Item1 is deprecated, you should use Item2 instead”, that should turn off the deprecation warnings.
@Scott Cadillac - thanks. I read that as “analyze warnings”… totally missed it.
Disabling generic warnings will disable all warnings, for any API. That’s not a desired behavior.
yes, I don’t think I’d want that.
[quote=458980:@Rob Hallock]Why… I wish I new why.
IMO Date was not broken and in their blog post, they talked about doing minimal harm…
I have piles and piles of refactoring to do.[/quote]
It didn’t have SecondsFrom1970. I subclassed my own class from Date and added it. I’ve just found that switching to DateTime is essentially trivial. So that’s good.