Leaderboard

Yes. And I've reported this issue some weeks ago as RSP-35049. The black text is caused by a bug in Vcl.Menus.pas; procedure DoThemedDrawText(): The parameter "Selected" is completely ignored in that code, but should be used to select to correct theme element details. Feel free to vote for it 😉. But even if this will be (hopefully) fixed in some Delphi 11.1 update I'm still looking for a workaround without using a full copy of Vcl.Menus.pas. Something like patching Vcl.Menus at runtime (using Delphi Detours? Or code from Andreas Hausladen's VCLFixPack?) to replace DoThemedDrawText() with a fixed version (see RSP-35049 for the required changes). Any help appreciated.

Most likely this: https://quality.embarcadero.com/browse/RSP-30870

Hello World, I just had a pleasant surprise - when I build a certain x64 project of mine, the executable is noticeably smaller under Delphi 11 Alexandria (6.5 MB) than under Delphi 10.4.2 Sydney (7.3 MB). Embarcadero must have done some serious optimizations. (Edit) the project is compiled with {$WEAKLINKRTTI ON}.

Indeed. I also add am IFDEF to error out when compiled with a newer Delphi version. Even if the problem is not fixed yet, the tweaked source is most likely no longer up to date anymore.

No, that only affects the ability to properly see the content of the list when debugging

I don't mean to compare Pascal to C. I just mean that Delphi has become less usable for low-level modular stuff because the executable size has become so big. Delphi 2009 was the last compiler that created really compact executables.

While it is a nice thing for some, ever since the use of floppy disks for data exchange has dwindled, the broader audience does not really care about exe sizes.

The Jcl project analyzer shows the largest differences in size to be in the following units. But there are small size reductions in many other units (rtl and mine). Delphi 10.4 Size Delphi 11 Size2 Diff Vcl.Themes 292380 Vcl.Themes 215,944 76,436 System.Classes 360524 System.Classes 314,652 45,872 SVG 124584 SVG 87,720 36,864 System.Threading 119156 System.Threading 87,640 31,516 System.Rtti 219480 System.Rtti 191,064 28,416

x86 PyScripter Delphi 10.4: 11,975 KB PyScripter Delphi 11: 10,326 K 14% reduction!!

Same here. PyScripter Delphi 10.4: 17,302 KB PyScripter Delphi 11: 15,523 KB 10% reduction, not bad. Any idea where this is coming from (generics?) Probably the first Delphi version that produces smaller executables that its predecessor.

It's all find and dandy to come up with all sorts of ideas that we as developers would love to see. But I believe that the reality is that most of the revenues come from corporations who are mostly interested in risk-reduction, not more usable software. I don't believe that EMBT is making most of their revenues from Delphi products because they're being actively used for new product development. Rather, I believe it's coming from corporations that built large apps between 2000 and 2010, and those apps are still producing strong revenues with modest investment in maintenance. These customers have been just running things as-is for the past 10-15 years, and they invest in minor updates to keep them operational. I believe the latest language enhancements are ignored, as are most of the new features. These customers simply keep renewing the maintenance agreements because it's the least-cost thing to do that minimizes their risks in case something unexpected happens. As one of the devs at a place I worked in 2009 liked to say, "We're all here just keeping a comatose patient alive long enough for them to migrate this project over to .NET." During the short time I was there, they missed the first two major milestones for that migration, and the schedule got pushed out by an additional year. The company was REALLY upset when Microsoft announced they were end-of-lifing Windows XP. I mean, these guys were so paranoid of changes to Delphi's math libs that they spent months running a HUGE bunch of regression tests on every new Delphi release looking for deviations in calculations less than 10^-6. Newer releases past D6 failed, and with MS abandoning XP meant it could cost them billions of dollars due to even the tiniest deviations in math calculations. I tried to move them to D2010, but one of their devs built some components that would make most folks here faint due to their total non-conformance with component building guidelines, and they wouldn't build properly under D2010. That's not to say there isn't new development and even innovation going on with Delphi in shops around the world. But it explains why the language itself is at least 10 years behind most contemporary languages; why the most urgent updates to the platform actually track updates that Microsoft, and now Apple, make in their latest hardware and/or software releases; why the run-time technology (like high-DPI stuff) hasn't gotten much attention (because most applications are running on machines barely capable of displaying full HD resolution); and why nothing reflects much concern for anything other than Microsoft, Windows, and making the run-time libs more similar to C# libraries than anything else (IMHO). ********************** If you want to see REAL INNOVATION in this space, take a look at what TMS Software is doing. They've created a more intentional and cohesive extension of the Delphi platform in the past 18 months than EMBT has done since they bought the company from CodeGear. I can't say for sure, but I suspect a larger percentage of their revenues come from developers who have a larger say in their future wants, needs, and desires than your average IT Manager or CIO. They're actually intersted in things that are not tied to Microsoft or Apple and extend into a more homogeneous cross-platform ecosystem that has web development in the center of everything. They are solving difficult multi-platform problems that EMBT should have been working on for 5+ years now if they really cared. And they are not waiting for EMBT to address any of the shortcomings they may encounter. One of their key players, Dr. Holger Flick, has written and published three (3) new books in the past 18 months, with more coming! With TMS tools, you don't even need Delphi to build Delphi apps that run in more platforms than EMBT supports TODAY! (See the screen-shot below) You can build them in Visual Studio Code, and using Lazarus you can even build executables that run natively on Linux machines without having to spend thousands of dollars on an "Enterprise Edition" Delphi license. We don't need more threads trying to lay out a direction that EMBT can take to make Delphi nicer for Developers, because Developers are clearly not EMBT's target market. (I don't know about you, but in the past 15 years, I've been the only person every place I've worked who had my own personal Delphi license to ensure I could keep up with new developments. That's because the production code at most places was a few releases behind the latest Delphi release.) Get invovled with TMS products and see if there's something there worth focusing on. Not their older VCL, FMX, and Intraweb (gawd, is that still around?) libs, but the newer WebCore, FNC, and Business Suite stuff. Their next release of WebCore will let you create web apps that run natively in more platforms than Delphi supports, including Raspberry Pi -- without requiring you to have access to a compiler that generates ARM code. And you won't need to have your dev machine tethered to another dev environment to do cross-compiles. (I know this is going to raise some hackles, so ... I say it's "native" because there's a wrapper that runs as a native app and it allows the code encapsulated inside of it to run within a web browser. There's no hardware that runs javascript in the same way there's nothing that runs java bytecode.) The photo below is a snapshot from a video they posted recently illustrating support for the Raspberry Pi. that shows the platforms WebCore will support in its next release (which will probably be out before EMBT releases their first "bug-fix" update for D11) using either Delphi or VSC as your dev platform. Their strategy does NOT depend on what Microsoft or Apple may or may not do, or what the next release of .NET or iOS might provide. WebCore targets javascript running in the web browser, which is becoming more universal than Windows. I invite all Delphi developers to stop complaining about what EMBT is NOT doing and start cheering on and supporting these guys who are actually INNOVATING around the Delphi language and EXPANDING the Dephi ecosystem -- RAPIDLY! (Buffalo Springfield's song, "For What It's Worth" is echoing in my head...)

No, as it depends on modified emba/another non-free codes I will not be able to publish it ever... 😕