Leaderboard

Final version of my eBook Delphi Event-based and Asynchronous Programming has been released - 291 pages. You can find more information and purchase option at: https://dalija.prasnikar.info/delphiebap/index.html Thanks to all of you who purchased the incomplete pre-release version (179 pages) of my eBook! After a minor delay, the full version is here! You can download it through the same PDF/epub/mobi links that you have received earlier from FastSpring via email. The subject line of that email message was: "Your Delphi Event-based and Asynchronous Programming - Part I Delivery Information". If you have any problems, feel free to contact me via the contact form on my site. Thanks again! Happy Holidays to you all!

+1 to the post above. Storing dates as strings is bad idea in most cases. Just don't do it. If you really REALLY have to do it, then use carved in stone format that won't depend on current locale settings. And don't forget the timestamps could contain timezones

Why are these dates stored as strings in the first place? If they are in a database they should be in a date field. If they were entered with a date picker, they should be TDate or TDateTime variables. If you want to store them as strings in a database for whatever reason, store them in a standard format: ISO 8601, and document that format. Don't rely on your users having Windows configured for any particular date format, you will find somebody who didn't, especially if your program is used in more than one country. And keep in mind, that date formats can be ambiguous: 01/12/15 can be 12 January 1915 or 12 January 2015 (American format), 1 December 2015 (British format), 15 December 2001 (some MSSQL format that looks like they got ISO 8601 wing). The only one I haven't seen so far is using the middle term for the year, but I'm sure some idiot will come up with that too. TryStringToDate by default uses the Windows settings, so that's out in this case. I wrote my own conversion and checking code for ISO 8601. It's in my dzlib if you are interested.

I hate complaining in public about our beloved Delphi because by doing so I add to the negative reputation that it has. So, first: here are some positives: I'm a big fan (and decades-long user) of Delphi. I used Delphi at a Fortune 1000 company where we created several very successful, industry-changing, million-line international applications with it. I use Delphi now in a smaller company to create award-winning products for macOS and Windows. Delphi (and Turbo and UCSD Pascal before that) has been a major contributor to my successful career. But, here's the negative: I'm tired of wasting money on annual maintenance plans. But I need them to fix older bugs or for fixes or access to new platforms. It seems I always have to wait until the first few bug-fixing patches from EMB. If I don't wait until one or two patches have been released, it seems that I and the rest of us becoming unwitting beta testers for EMB. But, now, it's worse: I am totally unable to use Sydney to develop our products. This problem is a memory leak. It was reported last summer: https://quality.embarcadero.com/browse/RSP-30215. And it hasn't been fixed by EMB. This bug prevents us from being able to compile our product in Sydney because we depend on the (wonderful) Mitov libraries which the bug affects. So, the subscription we paid for almost one year ago has been useless to me. The above URL contains a simple sample code to reproduce the problem. EMB has acknowledged the problem. I'm told that a workaround was proposed by EMB but that the workaround would take an enormous amount of time to implemented by us. I recently expressed the above concerns to Marco and Jim. But, I have not heard back anything positive. I'm worried that they may have once again postponed fixing this bug. So I thought I'd post about it here. If you're using the Mitov libraries, you're in the same boat as I am. I hope you (and anyone else reading this) will vote for this issue at the above URL so that perhaps it will be fixed in the near future. Meanwhile, I'm stuck paying for updates that don't work. From my perspective, EMB's programming team appears to be seriously under-resourced. I am very worried that Atana Popov and the group that manages Delphi has abandoned the product and are just squeezing as much revenue for as little investment as they can. It certainly looks that way from here. 😞

As I understand it, the source code of Mitovs libraries can be purchased. I would never rely of a library without the source.

Since the bug has workarounds, has Mitov updated his code to apply the workarounds until the bug is fixed?

Hi Team, Just to close this one off. I revisited all the various Date data entry points, 7 different dates in all, and confirmed they can only be either Null or a valid date. Then using my new Helper knowledge I created the following Helper based on Kas' suggestion.. { TQueryHelper } // Parameters are FieldNames in this case function TQueryHelper.AreDBDatesNull(const DateString1, DateString2: string): Boolean; begin // Result := (not FieldByName(DateString1).IsNull) and (not FieldByName(DateString2).IsNull); // end; // // Implemented by.. if MyQuery.AreDBDatesNull('Date1', 'Date2') then ..... Simpler, and testing the data fields directly rather than 'converting' them. Thank you all for your input & contributions. Have a Great 2021. Regards, Ian

Unbelievable(2)!!! Now I have to change my code pattern to avoid mistakes from Embarcadero developers.

@Tom F It's perfectly OK to complain, even better if you provide details when the issue is resolved or you made any progress with the Embarcadero. In last few years we see that just reporting bugs is not enough, they clear a lot of them but also introduce a lot of new ones. We all want Embarcadero to succeed in providing best Delphi versions, but if we keep our heads in the sand and not 'rock the boat' we are all doing ourselves a big disservice.

Fixed. Changes will be in 10.4 Update 2.

I just converted your code into an expert in revision #3418

That has NEVER been true, in ANY version... ... THAT is the correct behavior, in ALL versions. Auto-created Forms, like the MainForm, are owned by the Application object. They are not destroyed until the Application object is destroyed, which is after the main DPR code is done running and the VCL is being cleaned up. Nothing has changed. So the chance has to be something in your own code that is destroying the MainForm before the Application object is destroyed.

This is information not a question: Yes I know, Oracle 8i is old and shout be replaced. But there companies, with legacy software. When I read the Embarcadero information, It should work ( version 8.0.3 and later. (http://docwiki.embarcadero.com/RADStudio/Sydney/en/Connect_to_Oracle_Server_(FireDAC)) use: instantclient-basic-win32-11.1.0.7.0.zip), but you get the error: ORA-03134: Connections to this server version are no longer supported. Testing with local sqlplus learned the error is generated in the oracle part. (instantclient). I have installed version 10.2.0.5 and sqlplus is working and fireDAC is working to . For older oracle databases the info from Embarcadero is not correct. and you should use 10.2.0.5 version of the Oracle client part.

I released quite a bit of interesting code to github over the years: YouTube DATA API v3 parsing: https://github.com/bLightZP/Delphi-YouTube-Channel-parsing-plugin-for-Zoom-Player Basic RSS feed parsing code: https://github.com/bLightZP/Delphi-RSS-feed-parsing-plugin-for-Zoom-Player TheAudioDB MetaData/Image scraping code: https://github.com/bLightZP/Delphi-theaudiodb.com-Zoom-Player-media-scraping-plug-in TheMovieDB MetaData/Image scraping code: https://github.com/bLightZP/Delphi-themoviedb.org-Zoom-Player-media-scraping-plug-in OpenSubtitles.org subtitle search & scrape code: https://github.com/bLightZP/Delphi-OpenSubtitles.org-API-support-for-Zoom-Player A basic cross-platform calculator https://github.com/bLightZP/ElegantCalculator https://play.google.com/store/apps/details?id=com.inmatrix.ElegantCalculator Adapted old code to work as cross-platform pure-pascal image scaling with filters (bicubic, bilinear, etc): https://github.com/bLightZP/ImageInterpolation Adapted old code to work as a cross-platform drawing of an anti-aliased circle (can be modified to draw rount-rect as well): https://github.com/bLightZP/AntiAliasedCircle I forked a QRCode generating source code and greatly optimized it (~ x50 faster): https://github.com/bLightZP/DelphiZXingQRCode The original Delphi scanline color-conversion implementation was very slow, so I optimized it: https://github.com/bLightZP/OptimizedDelphiFMXScanline