Leaderboard

New compiled demo - Office file viewer http://delphihtmlcomponents.com/filebrowser.zip

Why don't we have a bunch of cool visualizers in the IDE when it's pretty easy to make? (let's see how video embedding works, youtube had a very bad video quality) In the video there is a TStringList Visualizer I put together. Visualizer.mp4

Data please or I call that fake news

More than visualizers I wish some stable, reliable debug evaluation in the first place, under all platforms .

Have you received UPS/DHL packages recently ? Make a test, how important the signature nowadays is ... I could even make 3 crosses, and nobody complains.

RTF, DOCX, DOC, XLS, XLSX, PPT, PPTX, SCX

Due to the sluggish behavior of the themed IDE in some of the later versions I decided to buy a new PC. It turned out that the overall power consumption of the new PC is lower than that of the previous one even with a significantly better performance.

Hi Ian, I'm not sure if it helps as I don't know Thinfinity, but this is the unit I made for capturing signatures. Just create the class with a TImage in the construcor parameter: imgSigno: TImage; .... FSigno := TSigno.Create(imgSigno); FSigno.OnChange := OnChangeSigno; On the OnChange you can do some validation or GUI events like enabling a button OK. You can set the FSigno.PenWidth to fine tune the signature quality. On SaveAs* the image will be cropped to the actual signature to minimize the image size. You can use it as you want if it works or helps. Signature.pas

I was surprised by @dummzeuch's benchmark results, so ran my own. In short, I created 44350 strings by taking 8870 English words and appending 1 to 5 to them, added half of them (index odd) to the data structure, to finally check for all of them if they were present. The experiment was repeated 100 times, and the listed results are the average total time for each action: TStringList - Add: 143.44 ms - TryGet: 123.09 ms TStringHash (Size = 256) - Add: 23.58 ms - TryGet: 62.56 ms TStringHash (Size = 512) - Add: 17.09 ms - TryGet: 40.54 ms TStringHash (Size = 1024) - Add: 13.47 ms - TryGet: 29.3 ms TStringHash (Size = 2048) - Add: 11.45 ms - TryGet: 21.68 ms TStringHash (Size = 4096) - Add: 10.2 ms - TryGet: 18.41 ms TStringHash (Size = 8192) - Add: 9.49 ms - TryGet: 16.28 ms TStringHash (Size = 16384) - Add: 9.17 ms - TryGet: 15.21 ms TStringHash (Size = 32768) - Add: 8.73 ms - TryGet: 14.24 ms TStringHash (Size = 65536) - Add: 8.68 ms - TryGet: 14.03 ms TDictionary - Add: 10.2 ms - TryGet: 16.09 ms TSynDictionary - Add: 9.02 ms - TryGet: 14.99 ms If you're really interested, I can send you the code, but I think these results make sense. As long as the number of buckets is somewhat appropriate, a TStringHash outperforms TDictionary even. Possibly the former has a more specialized hash function, or simply does less other work (e.g. no accounting for reallocation). Note that I did make it fair by checking for duplicates in TStringHash too. If you don't need that, it becomes even faster.

For what it's worth, here's a few different responses: One answer is keeping up to date with changes to Microsoft Windows... for example HighDPI support. Does your software work well with Windows 10 high dpi systems? Delphi is getting much better with this particular issue. Hopefully 10.4 finally fixes some of the issues with VCL Styles and High DPI. Another answer is compliance related - some compliance certifications require your tooling be kept up to date with all available patches/updates. If you aren't under third party audits, this is less of an issue but for security in general keeping current is wise. (Do you have the buffer overflow fix for Delphi in place?) Another answer is business risk / insurance related - It may bite you later on any future insurance claims that you knew you were out of date but didn't upgrade to fix any potential problems. Are you going to milk this thing as it is until it dies, or are you ever going to add new features? If you are going to add features, staying current may make future features easier, especially keeping up with fast changing technologies like AWS/Azure. If you are using any third party components, eventually they will drop support for older versions of Delphi. You have to assume most of the new activity in third party components surround the new releases. With more and more new language features becoming available (like inline variables) that devs really like to use which aren't backwards compatible, the rate of third party components dropping support for old versions will probably increase over the next few years. This is obviously one of the prime goals of Embarcadero - and they will keep hammering at. It's in their best interest to introduce new non-backwards compatible language features and this approach will succeed over time. Finally, the longer you wait, the harder it becomes to ever bring it back up to date. It's just delaying the cost today for higher costs tomorrow. If they are in it for the long term, they should act like it. If you are a one or two-man shop then it's certainly much harder to justify the ongoing costs due to the ever increasing price (which I assume will keep getting worse), but if you are making a decent living with the Delphi products then it only makes sense to keep them current.

Experience shows that this usually never happens - and if, it will not happen in the expected time frame, cost and functionality. The first barrier is usually the lack of documentation what the Delphi software does, how it does it and why it does it that way. I personally have seen a couple of such endeavors going down the drain. They could as well have burned the money in the first place.

Uwe, thank you for your information. Why does Embarcadero use ambiguous terms (and possibly not explain them in the UI)? A user could easily believe that "Upgrade" means upgrading to the new version 10.3.3.