Leaderboard

Don't tell me - but this the almighty excuse brought up by the decision makers almost every time some issue like this is brought up - "but what about existing code" - like for that dreaded "directly passing result of ctor call to interface parameter issue" - what about existing code? Well existing code is most likely suffering from a defect. The stupidity of the Delphi compiler in almost every aspect and the unwillingness to change anything significant on that is making me furious!

Updating a single application even if complex is not a hard task, almost every other major IDE out there can do it. Only Delphi developers have to manually apply hotfixes by unzipping some archive and unblock the contained binaries...

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

Just confirmed by @Marco Cantu installation support is free if you have active subscription.

Well that's one of the drawbacks, when you switch from boring old monolithic to DLL/BPL/.net hell (preferebly a mix of all three, just to make sure). And no, @PeterPanettone I do not think a 12 year old developer should be confronted with this madness, it would scar the poor child for life.

I created ticket in SourceForge: Invalid row selection when trying to go to the sections in the plugin Go to

If the question is about of language choice, than I would recommend (as I do for my projects): first of all I would prefer python for scientific calculations and operations, but I don't like it because of its script language and I couldn't compile it in a lib/dll/exe, even if I do use it in some projects than, if the choice for scientific calculations and operations was not in favor of python, I would chose C++, it could be used to build DLLs for later use and last but not least, I prefer Delphi for visual/database/networking applications programming, here I can use my DLLs created in C++ What I wanted to say is that you should not stop looking in one direction, there is no just one solution for developing a project, its up to you what to chose, but need to think before and model your project before all.

Lars understands that, I think, and wonders why the compiler doesn't take the same view and issue a warning.

Keep voting: https://quality.embarcadero.com/browse/RSP-13290 And given that the compiler already knows line numbers and the filepath it's working on for Assert it should be almost no effort to implement something like this as well: https://docs.microsoft.com/en-gb/dotnet/api/system.runtime.compilerservices.callermembernameattribute?view=netframework-4.7.1

Based on experience I am against this type of data storage for several reasons: - Some database engines can not search in BLOB fields. Now it might not be an issue in the beginning but it makes investigating data corruption / debugging processing issues a living nightmare - Downloading blob fields are slow, no matter what. Especially over the network. In our production databases I can select hundreds of thousands of rows with 150+ columns but only a fraction of that 2 fields: an ID and a BLOB storing an XML - Database engines are robust, they were built for having columns. While it can be hard / intimidating to see the relations at first time, they have no issues handling a larger number of columns - Unless the DB engine has built-in JSON support, you'll not be able to query and compare a specific value on database side, you'll always have to download and compare from code, increasing memory, network and CPU usage of your program. Considering a well-fed metal (our slang for a server with enough resource + overhead) running the database, this will always be significantly slower than letting the DB engine to take care of these The only reasonable case when storing a JSON / XML in a database I can see is if you receive that from an external source (like a REST server or a 3rd party sending your software some information) and you want to keep those chunks for auditing purposes. Sooner or later you'll face one of the issues I mentioned, though 🙂 We did the same about 8 years ago (only with XMLs) and now we are looking into opportunities to undo it...