Leaderboard

To some extent theming has a purpose because without it you could not have dark theme. Problem here is that Delphi (VCL Styles) based theming is just horrible since day one (even before it was introduced in IDE). Instead of VCL Styles being fixed and then used at large, EMBT choose to use VCL Styles without fixing issues. Another problem is not that just in theming itself, but revamping Options dialog layouts without making proper alignment/size adjustments - so everything visually just falls apart.

I really don't get the whole theming bull anyway. I set my windows to look exactly the way I want it, and along comes some wannabe designer and imposes his take on what a GUI should look like. Most of the time it's just hilarious, but when I have to work with a tool (yes a tool) I want it to be as unobtrusive as possible and just do it's thing. If i want glitter on a hammer I will buy glitter and stick it on there myself. Don't expect everyone to like glitter an a hammer. Jeeeez! </Rant>

And they even removed the checkbox to disable theming from the IDE settings dialog in 10.3.1. Instead of fixing the obvious problems with said dialog. There still is a registry setting (probably left unnoticed 😉 ) which disables theming but they may as well remove it in the future releases leaving us with an unusable IDE... I wish all resources spent on this theming nightmare since XE2 (? don't remember when it all began) were allocated to real bug fixing.

CrossVCL 1.07 just released. New build contains bunch of fixes and improvements. Start building macOS and Linux VCL apps with Embarcadero Delphi and CrossVcl. We are working on Toolbar 2000 and TBX support. Work in progress still. Look at screenshots from macOS and Linux. And video - https://youtu.be/E34-3S05_IE History at: https://crossvcl.com/history.html More Info: https://crossvcl.com

It's more complex than that. Maybe for users of System.Generics.Collections. But what about those of us that write our own generic types?

Don't know about GExperts, but theme support is by far the most often requested feature for MMX Code Explorer. I for myself am not a fan of the dark theme and I even could do without themes at all. On the other hand there are obviously a decent number of developers eagerly waiting for it.

The new IDE skinning is a disaster. So! freaking! slow!

Like the events of most other components, the events of Indy components expect class methods, not standalone functions. You could go the way that others have recommended, where creating a TDataModule at design-time and using it at run-time would be the easiest. But, even if you were to simply write a class in code to wrap the events, note that you don't actually need to instantiate such a class at run-time, you can declare its methods with the class directive instead, eg: program IndyConsoleApp; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, IdContext, IdBaseComponent, IdComponent, IdCustomTCPServer, IdTCPServer, IdGlobal; var IdTCPServer1: TIdTCPServer; procedure ShowStartServerdMessage; begin WriteLn('START SERVER @' + TimeToStr(now)); end; procedure StopStartServerdMessage; begin WriteLn('STOP SERVER @' + TimeToStr(now)); end; type TCPServerEvents = class class procedure OnExecute(AContext: TIdContext); end; class procedure TCPServerEvents.OnExecute(AContext: TIdContext); var LLine: String; begin LLine := AContext.Connection.IOHandler.ReadLn(); writeln(LLine); AContext.Connection.IOHandler.WriteLn('OK'); end; begin try IdTCPServer1 := TIdTCPServer.Create; try with IdTCPServer1.Bindings.Add do begin IP := '127.0.0.1'; Port := 6000; end; IdTCPServer1.OnExecute := TCPServerEvents.OnExecute; IdTCPServer1.Active := True; try ShowStartServerdMessage; Readln; finally IdTCPServer1.Active := False; StopStartServerdMessage; end; finally IdTCPServer1.Free; end; except on E: Exception do WriteLn(E.ClassName, ': ', E.Message); end; end. However, there IS actually a way to use a standalone function instead, but it involves a little trickery using Delphi's TMethod record: program IndyConsoleApp; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, IdContext, IdBaseComponent, IdComponent, IdCustomTCPServer, IdTCPServer, IdGlobal; var IdTCPServer1: TIdTCPServer; procedure ShowStartServerdMessage; begin WriteLn('START SERVER @' + TimeToStr(now)); end; procedure StopStartServerdMessage; begin WriteLn('STOP SERVER @' + TimeToStr(now)); end; procedure TCPServerExecute(ASelf: Pointer; AContext: TIdContext); // NOTE THE EXTRA PARAMETER! var LLine: String; begin LLine := AContext.Connection.IOHandler.ReadLn(); WriteLn(LLine); AContext.Connection.IOHandler.WriteLn('OK'); end; var ExecuteFct: TMethod; begin try IdTCPServer1 := TIdTCPServer.Create; try with IdTCPServer1.Bindings.Add do begin IP := '127.0.0.1'; Port := 6000; end; ExecuteFct.Data := nil; // or anything you want to pass to the ASelf parameter... ExecuteFct.Code := @TCPServerExecute; IdTCPServer1.OnExecute := TIdServerThreadEvent(ExecuteFct); IdTCPServer1.Active := True; try ShowStartServerdMessage; Readln; finally IdTCPServer1.Active := False; StopStartServerdMessage; end; finally IdTCPServer1.Free; end; except on E: Exception do WriteLn(E.ClassName, ': ', E.Message); end; end.

Hi Developers, Deleaker was created in 2006, and is been support Visual Studio from the very first release. Now it's time to find leaks in Delphi and C++ Builder! Deleaker finds memory leaks, leaks of GDI and USER32 resources, handles and many others. Deleaker fully integrates with RAD Studio. Here the official announcement: https://www.deleaker.com/blog/2019/03/11/integration-with-rad-studio/ Let's look how it works! Download Deleaker and launch it. Now you can select versions of RAD Studio you want Deleaker to integrate with. Of course, RAD Studio Rio 10.3 is supported: Deleaker is installed, let's launch Delphi: Great, Deleaker is here: Let's add some leaks: Start debugging, click the button, exit. Deleaker is taking a snapshot: Two leaks are shown as expected. It's easy to navigate to source of a leak: Happy coding!

First 2 loops are O(log n) and O(log m). The last loop is clearly O(9) due to the bound but the O(9) is "asymptotically equal" to O(1). Overall you have O(log n + log m + 1) where 1 is constant so only n and m are involved. That complexity is O(log n + log m) but to be correct it would be O(log max{m, n}) where max gives you the biggest value between m or n. Do not say that for loops are O(n) by default, that would be a wrong assumption! Example here: https://stackoverflow.com/questions/10039098/why-is-this-function-loop-olog-n-and-not-on Look this example: var x: double; //x = 1000 maybe while (x > 1) do x := x * 0.3; You are executing this loop many times, let's say n, and so you are taking x * (0.3^n) and you want it to be bigger than something, in this case 1. Now you need to get n from that equation but n is an exponent so you can use logarithms to take the n down like: x * (0.3^n) = 1 -> log(0.3^n) = log(1/x) -> nlog(0.3) = log(1/x) and so on, at the end you'll get an asymptotic O(log n). This is probably not the place to demonstrate what I am saying but if you understand math topics like "limits" and "asymptotes" you can google for this and see that there are methods like substitution, master theorem or trees to get the O(something) notation

The complexity is linear with the number of digits. In this case it's probably much easier to write the code if you convert each number to text. You then need an array of counts for each digit. Count the digits. Finally check that each digit has the same number of occurrences. In practical terms, complexity arguments aren't actually going to be relevant here. It's the constant of proportionality that will matter most in performance.

The bad thing about the IDE theming is that it's not even using the default VCL theming but a different one hacked into the IDE code because they did not find a better way than that to avoid the form designer being themed. That and doing obvious bad custom drawing such as the search bar in the title bar which keeps jumping around when you move the window. Also not a fan of the dark theme in RAD Studio - in Visual Studio and Visual Studio Code I use it all the time - simply because its the default and it works just nice - the default colors in the code editor fit nicely and the entire IDE is still very reactive. And even though there are also places where some UI controls are not themed in dark (like the project properties) it still works well together without cut off controls and useless scroll bars because some control is 2 pixels to wide.

I see pretty much the same code in 10.3 as produced by XE7 in my real world app, using the Windows x64 Delphi compiler. Performance is identical. Still significantly worse than could be achieved by the mainstream C++ compilers. Probably worse than what could be achieved in C#!

You can still drop themeloader, themeXY, and of course moderntheme bpl too. Yes, it was also themed long before the "themes" (modernthemeXXX.bpl). But then you will face, how poor the new forms (like options) and some other parts are implemented. Un-/Wrong Aligned controls etc... And the "Standard" toolbar has a dark background, if I nuke modernthemeXXX.bpl and looking at the bare, winapi rendered IDE. And these things never will be fixed. But hey, on the other side, JAVA apps do not fall so slowly anymore.

For those who write their own generics, you have two ways to do this: the naive but generic way, which can still result in code bloat, and the System.Generics.Collections way, which goes against almost every prinicple of generics, i.e. that you don't have to repeat yourself ad infinitum. I wrote about that already: The current state of generics What they did with the new intrinsics solves part of the problem for their own classes, but it certainly doesn't solve the problem for us who would like to write generics without having to worry about code bloat and without having to do a lot of "copy-and-paste generics". If they can make the compiler select different pieces of code depending on these new intrinsics, they can just as well make the compiler generate such code without us having to worry about it. That is more work, but that is how it should be. In the meantime, they should also finally fix Error Insight (not only for the new inlined vars) and make the new themed IDE a lot more responsive.

And don't forget the resources spent on fixing that theming stuff, not just in the IDE but also in the IDE extensions. I spent several days just trying to fix things in GExperts that were broken due to introducing the theming bugs in theming bugfixes in theming And I am still not done. And GExperts doesn't even support theming itself, I don't want to consider the time it would take to actually support it (and I am definitely not going to spend that time).

A word of warning to those (I'm counting 50 since yesterday) that downloaded this version: If your resources contains bitmaps that were created by older versions of Delphi (or rather applications built with older versions of Delphi) then the resource editor might corrupt them on save. It appears that a bug was introduced in TBitmap between Delphi 2009 and 10.2. Here's the short version: The format of a windows bitmap is basically 1) Header, 2) Color table, 3) Pixel data. For bitmaps with PixelFormat>pf8bit the color table is optional. The Header specifies the number of colors in the color table (the TBitmapInfoHeader.biClrUsed field). Older versions of Delphi sometimes saved bitmaps in pf24bit/pf32bit format with a color table and the corresponding value in the biClrUsed field. This was unnecessary but harmless and perfectly legal according to the bitmap specs. Here's an example of what such a bitmap might look like: [File header] [Bitmap header, biClrUsed=16, biBitCount=32] [Pixel data] These bitmaps can be read by newer versions of Delphi, but when the bitmaps are written again they become corrupt. Delphi keeps the value in the biClrUsed field but fails to write the corresponding color table. The result is that the pixel data ends up at the wrong file offset. Here's an example of a corrupt bitmap: [File header] [Bitmap header, biClrUsed=16, biBitCount=32] [Pixel data] The reason why this is a problem for the resource editor is that it is built with Delphi 10.2. I have a fix for the problem but I'm not ready to release a new version with the fix. Here's the fix btw: // Fix for bug in TBitmap. // Saving bitmap with PixelFormat>pf8bit with biClrUsed>0 fails to save the color table // leading to a corrupt bitmap. type TBitmapColorTableBugFixer = class helper for TBitmap type TBitmapImageCracker = class(TBitmapImage); public function FixColorTable: boolean; end; function TBitmapColorTableBugFixer.FixColorTable: boolean; begin if (TBitmapImageCracker(FImage).FDIB.dsBmih.biBitCount > 8) and (TBitmapImageCracker(FImage).FDIB.dsBmih.biClrUsed <> 0) then begin TBitmapImageCracker(FImage).FDIB.dsBmih.biClrUsed := 0; Result := True; end else Result := False; end; The problem appears to be the same one reported here: Setting TBitmap.PixelFormat can lead to later image corruption or EReadError

var [weak] fib: TFunc<integer,int64>; Marking it as weak breaks the cycle. However, there was a bug with weak that is only recently fixed (not sure whether in 10.3 or 10.3.1)

Today I learned about pseudo random number generator driven FizzBuzz (https://stackoverflow.com/q/20957693) and I couldn't stop myself from porting it to Delphi ... program FizzBuzzRandom; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils; procedure FizzBuzz(upTo: integer); var i: integer; begin for i := 1 to upTodo begin if (i mod 15) = 1 then RandSeed := 1973472511; Write(TArray<string>.Create(i.ToString, 'Fizz', 'Buzz', 'FizzBuzz')[Random(521) mod 4], ' '); end; end; begin FizzBuzz(100); Readln; end.

Only because I've just uploaded a new version 🙂. It's been gone for at least 5 years. My ISP keeps flagging it as a virus (probably because it's built with Delphi) and taking it offline.