Leaderboard

The new Error Insight is GREAT! It works really well! After years of red squigglies for things that are not wrong, it is really nice to only see squigglies when something actually is wrong.

When you find a problem with RAD Studio, make sure to create a report in https://qp.embarcadero.com/ which has replaced the former https://quality.embarcadero.com See https://blogs.embarcadero.com/the-new-quality-portal-is-live-here-are-the-details/ for clues on how to use the new reporting platform. And - please describe the problem properly! What you are trying to do The actual result you got The result you expected Most important: How to reproduce the problem - either as a detailed step by step description - or as a small, self-contained, compilable example project - or both of the above Better reports = better chance of getting stuff fixed.

HTML Library 4.2 released. Mostly an maintanence release with RAD studio 10.4 support and bugfixes. Customers will receive download link in a two days.

FinalBuilder is a fully featured automated build tool, which supports Delphi 3 to 10.4, along with C++Builder 4 or later. FinalBuilder makes it simple to automate your entire build process, from compiling your delphi projects to compiling and uploading installers, creating ISO's. There are over 600 built in actions, with support for Git, Mercurial, Perforce, Subversion, TFS and many other version control systems. Unlike xml or batch file based systems, with FinalBuilder you can easily debug your build process, with breakpoints, step over, step into etc. Of course FinalBuilder also integrates with Continua CI - our continuous integration server product, and with other CI servers such as Jenkins. Thousands of Software Developers rely on FinalBuilder to automate the build, test and release process. If you are not using FinalBuilder to automate your builds, you are missing out. Download a fully functional 30 day trial version today.

Thank you for these awesome tools, Vincent! The combo is used to manage our builds, unit testing and devops style push to test facilities. We are very happy with Continua CI and FinalBuilder and cannot do without them!

This one is rather important fix - it is fixed for both LSP and Classic Code Insight Code completion does not work inside anonymous methods https://quality.embarcadero.com/browse/RSP-23252

The issue "Firemonkey form has no animation on minimizing and maximizing in Windows 10." was submitted like 20 times. That means there are duplicates, a lot of duplicates...

There you go: https://en.delphipraxis.net/topic/2887-you-rad-studio-104-sydney-appreciated-features-and-bug-fixes/

Will there also be a topic for 10.4 Sydney appreciated new features and bugs fixed?

This is actually true for all software products, so I pinned this.

The ICS V8.64 distribution includes packages and project groups to install on Delphi and C++ 10.4 Sydney. and is available via GetIt for 10.3 and 10.4, Angus

MMX version 15.0.15 now supports Delphi 10.4 Sydney.

I have mixed feelings about this stuff. One big one is that Borland / Inprise really dropped the ball back in the D6/D7 years when they thought it was a Good Idea to hitch their wagon to .NET and everything Microsoft. They made some improvements in the language that left a lot of customers in the dust holding a bag of rocks. Here we are today and they're complaining that these same users STILL don't think it's worthwhile to invest in moving past D6/D7. Sheesh. Developers cost 2x-3x more today than they did back then, and if it didn't make financial sense to upgrade back then, then surely it makes worse sense today. Embt is not making any more friends complaining about the resources these legacy clients are costing them. The problem isn't the compiler -- it's the 3rd-party components like Dream Components that died on the vine and couldn't easily move forward. If they want to fix the problem, Embt should consider buying the rights to these old component libs and investing their own resources in making them work on the latest versions of Delphi. Add them to GetIt and give people a legitimate upgrade path. Whoa! What a novel idea! Still, a lot of folks still won't consider upgrading because it's harder than ever to find developers with solid Delphi skills today. (I think it's easier to find COBOL programmers today than Delphi folks!) Another option is to have a separate maintenance program for legacy products. I have not found a single job in the past decade doing NEW Delphi work -- it's all supporting LEGACY apps that were written in the D4-D7 years. Maybe they're using newer versions of the compiler, but it seems silly to me that the company is COMPLAINING about the fact that all of these old legacy clients are refusing to pay their ridiculous maintenance fees to stay exactly where they are. It's nice that Embt wants people to move forward, but until more jobs start showing up for NEW DELPHI PROJECTS, they're doing little more than Sisyphus pushing a rock up a hill while complaining about the effort involved. They (previous Mgt) created this problem but they don't seem to want to fix it. The world is moving to Open Source Software. Delphi is one if the few remaining products that's not just NOT OSS, but VERY EXPENSIVE for commercial use. Microsoft subsidizes the crap out of their dev tools, as do others like IBM and Oracle. I think the best thing for Delphi would be for Embt to push to get Delphi acquired by a company that can afford to move it in the direction of OSS by subsidizing it from other product revenues. Instead, they keep raising the costs to customers who are mostly using it to MAINTAIN OLD CODE. I'm working on my 4th or 5th gig since 2009 that's maintaining code written prior to D2007 and it hasn't changed at all. The company has NO PLANS FOR FURTHER DELPHI DEVELOPMENT beyond maintaining their legacy code. They pay for maintenance updates, but so what? A couple of places I worked are extremely hesitant to allow any sort of large-scale refactoring -- they say if they wanted to invest in that amount of work, they'd just assume switch to rebuilding the thing from scratch in C#/.NET or something else -- not Delphi. WHERE ARE THE NEW PROJECTS THAT ARE CREATING MORE DELPHI JOBS? This is a MARKETING PROBLEM for Embt. I don't think they have any right to complain when they have steadfastly maintained a posture that has gotten them exactly nowhere in the market. There's no evidence that their products are being used for more NEW product development than to support LEGACY projects. Where's the beef? Or rather, Where's the NEW work? (And don't respond with, "well, we're doing new stuff!" If you are, say how many devs you've hired to help with the NEW stuff vs. to maintain the OLD code. Rather, show me, say, 10 job postings made to any of the popular job boards that are legit posts to hire people for NEW DELPHI-based projects. Nobody hires new devs for new Delphi work -- it's a reward given to long-time employees. The new-hires are almost always for back-filling open spots maintaining the old code. We've lost 3 people in the past 6 months who worked with Delphi, and I'm the only new-hire to replace one. Now Mgt is running around like chickens with their heads cut off because they failed to plan for this. Two of these guys left to work on stuff that's "more fun"; one non-Delphi and one is another legacy project but with some slow growth of new features. EVERYTHING I've seen in the past decade, or been contacted by recruiters about, has been MAINTAINING LEGACY CODE. I've found NO NEW WORK on Delphi, especially within 500 miles of where I live.)