RAD Studio 13 is available

[Attila Kovacs 692]

Obviously, I also didn’t read what you wrote, and for that reason it’s working as expected. I think I won’t read anything from you, so I don’t break the system.

[dummzeuch 1717]

1 hour ago, PeterPanettone said:

Is dummzeuch an Illuminati expert? 

Do Illuminati experts hate jokes?

No, I am one of them. And of course I hate jokes.

[PeterPanettone 180]

6 minutes ago, dummzeuch said:

I hate jokes.

Do you have a particular reason for hating jokes - perhaps if they are not 64-bit? 😉

Edited Saturday at 01:54 PM by PeterPanettone

[FredS 140]

3 hours ago, PeterPanettone said:

I think I've found the bug: When entering something in the search box and then removing the search box content with the BACKSPACE key, the search box content is not really removed but only made INVISIBLE. Only when clearing the search box content by clicking on the "x" pseudo button, the search box content is really removed. That's a common bug that often occurs in Delphi development when a feature is not carefully tested.

This annoyance did happen but seem fine in the release.

[PeterPanettone 180]

On 9/12/2025 at 10:16 AM, Patrick PREMARTIN said:

For the search by word they used the same behavior as "find" option in source editor. Suggesting more options could be a good thing too.

 

We don't have to wait for next major release, it could be done for an update.

The SmartSearch principle is very simple:

function ContainsSearchTerm(const AText, ASearchTerm: string): Boolean;
// returns True if:
// if ASearchTerm is single word:                       if AText contains ASearchTerm
// if ASearchTerm is multiple words (devided by space): if AText contains all words
var
  LWords: TArray<string>;
  LWord: string;
begin
  // Return False if ASearchTerm is empty
  if System.SysUtils.Trim(ASearchTerm) = '' then
    Exit(False);

  // Split search term by space
  LWords := ASearchTerm.Split([' ']);

  // If there's only one word, check if AText contains that word
  if System.Length(LWords) = 1 then
  begin
    Result := System.StrUtils.ContainsText(AText, ASearchTerm);
  end
  else
  begin
    // Multiple words: AText must contain all words
    Result := True;
    for LWord in LWords do
    begin
      if not System.StrUtils.ContainsText(AText, LWord) then
      begin
        Result := False;
        Break;
      end;
    end;
  end;
end;

 

Here is a shorter optimized version:

 

function ContainsSearchTerm(const AText, ASearchTerm: string): Boolean;
var
  LWords: TArray<string>;
  LWord: string;
begin
  // Split search term by space, filter out empty words
  LWords := Trim(ASearchTerm).Split([' ']);
  if Length(LWords) = 0 then
    Exit(False);

  // Check if AText contains all non-empty words
  for LWord in LWords do
    if (LWord <> '') and not ContainsText(AText, LWord) then
      Exit(False);

  Result := True;
end;

 

Edited Saturday at 05:23 PM by PeterPanettone

[PeterPanettone 180]

Like many code editors, the Delphi source code editor (both 12 and 13) has a useful feature:

 

Clicking the Line Number selects the whole Line. This allows you to easily copy an entire single line by first clicking on a Line Number and then pressing CTRL+C.

 

However, this does not work when clicking on the LAST DIGIT of a line number!

 

Is this a bug or a configuration issue? Or is it due to HighDPI interference?

Edited Sunday at 10:44 AM by PeterPanettone

[David Duffy 1]

9 hours ago, PeterPanettone said:

Obviously, you didn't read what I wrote. I wrote: "removing the search box content with the BACKSPACE key".

 

1. For example, enter "kirk"

2. Then, remove the whole content "kirk" with the backspace key.

3. Result: Not all 104 items are restored.

I can't replicate your issue either.

[PeterPanettone 180]

1 minute ago, David Duffy said:

I can't replicate your issue either.

You should know that computer programs are not deterministic, especially complex computer programs like the Delphi IDE. So, a statement like "but it works on my computer!" is a typical statement from computer illiterates.

[PeterPanettone 180]

Then it is probably a HighDPI interference. Tell me the specifics of your monitor.

[PeterPanettone 180]

12 minutes ago, David Duffy said:

I can't replicate your issue either.

Why are you repeating this to me? Sorry, but I can't help you.

[David Duffy 1]

Okay then. Have a nice day. 🙂

[PeterPanettone 180]

1 minute ago, David Duffy said:

Okay then. Have a nice day. 🙂

You too, have a nice day. 

[luciano_f 7]

One question: Can the 64-bit IDE generate 32-bit Exe ?

   If it can't, will it be able to do so in the future and next versions ?

[pyscripter 837]

25 minutes ago, luciano_f said:

One question: Can the 64-bit IDE generate 32-bit Exe ?

No.

25 minutes ago, luciano_f said:

   If it can't, will it be able to do so in the future and next versions ?

Who knows, maybe sometime.

[DelphiUdIT 265]

10 hours ago, luciano_f said:

One question: Can the 64-bit IDE generate 32-bit Exe ?

   If it can't, will it be able to do so in the future and next versions ?

 

9 hours ago, pyscripter said:

Who knows, maybe sometime.

 

I doubt it. Embarcadero has said it will maintain the 32-bit IDE for some time, and I think 32-bit application development will stop there.
Many manufacturers no longer support 32-bit technology, so I doubt Embarcadero will invest in porting 32-bit application development to the new 64-bit IDE.

Of course this is my personal feeling.

[PeterPanettone 180]

4 minutes ago, DelphiUdIT said:

Many manufacturers no longer support 32-bit technology

Possible scenarios for the upcoming 128-bit technology:

 

• Specialized applications such as scientific calculations or cryptography could benefit from it

• Very large databases or in-memory computing could potentially require it

• New areas of application that we cannot foresee today

[Uwe Raabe 2201]

13 hours ago, luciano_f said:

Can the 64-bit IDE generate 32-bit Exe ?

Yes, albeit not really straight forward. Also the Win32 platform has to be enabled for the project, which will always be the case when you create a new project even inside the 64-bit IDE.

 

The trick is to create a Build Group and include Win32 as target platform in it.

[Davide Angeli 45]

On 9/12/2025 at 11:38 AM, Oboba said:

Does anyone know if madExcept is going to be updated to support this new Delphi version? Latest news on the madshi website is from 2023 and their forums are dead 😞

I've written to the devoleper and it seems he is working on it. It should release an update this week.

 

In general, however, I find it frustrating that component devolepers wait for the official release of the new Delphi to start working on updating their products. I can understand small developers, but there are some big-name suites that haven't made an update available yet (TMS, for example). Shouldn't the beta releases of the IDE also serve this purpose? Having the source code allows you to improvise a recompilation, but that's always time stolen from development, because you always have to make small adjustments to source code that isn't our own.

[Angus Robertson 677]

Quote

I find it frustrating that component devolepers wait for the official release of the new Delphi to start working on updating their products. I

Why would you think that?   

 

Perhaps compiler changes during the beta process mean developers can not know their software will work until RTM, which is only a few days before announcement. 

 

And that announcement date might be unknown to developers even after RTM, so they can not schedule work ahead.  

 

Major new releases do seem to happen in September, meaning many developers have been away on holidays during the summer, so may not have been participating in the beta process that closely.   Or they may simply have been busy on other issues.  

 

Sure developers can prepare before RTM, but you can not trust any components not properly tested on RTM. 

 

Angus

 

 

  

[Oboba 3]

On 9/14/2025 at 2:17 PM, DelphiUdIT said:

 

 

I doubt it. Embarcadero has said it will maintain the 32-bit IDE for some time, and I think 32-bit application development will stop there.
Many manufacturers no longer support 32-bit technology, so I doubt Embarcadero will invest in porting 32-bit application development to the new 64-bit IDE.

Of course this is my personal feeling.

This would be an extremely bad decision. In my case, in different applications, the 32-bit exe works 30-40% faster than the same code, compiled in 64-bit. It seems that the 64-bit compiler is not mature enough in Delphi, optimization and generated code is not as good as 32-bit. I can also add a lot about compiling speed and debugging in Delphi 64-bit but I'm too lazy to type all this. So I hope the 32-bit compiler stays with us for many years to come.

 

Bug part of my work is service applications for Windows Server and I ship all of them as 32-bit exes - speed and reliability is just so much better.

[DelphiUdIT 265]

@Oboba

I didn't say that Win32 IDE, with which you can produce x86 EXE, will be abandoned in a near time.

As I said (or better Embarcadero said), the 32-bit IDE will still be maintained, so you will not have any issue.

 

Edited Monday at 07:48 PM by DelphiUdIT

[Brandon Staggs 393]

On 9/12/2025 at 10:36 AM, PeterPanettone said:

Perhaps they wanted to avoid any connection to the unlucky number 13?

Someone forgot to tell the guy who made the splash screen then.

[dummzeuch 1717]

1 hour ago, Brandon Staggs said:

Someone forgot to tell the guy who made the splash screen then.

That guy seems to be colour blind anyway, so maybe he overlooked the 13 because it has the wrong colour?

 

Edit: Sorry, I was referring to the guy who made the Welcome Page, not the splash screen.

Edited 16 hours ago by dummzeuch

[PeterPanettone 180]

1 minute ago, dummzeuch said:

That guy seems to be colour blind anyway, so maybe he overlooked the 13 because it has the wrong colour?

Still angry with jokes? Please calm down.

[johnnydp 25]

On 9/15/2025 at 4:54 PM, Oboba said:

This would be an extremely bad decision. In my case, in different applications, the 32-bit exe works 30-40% faster than the same code, compiled in 64-bit. It seems that the 64-bit compiler is not mature enough in Delphi, optimization and generated code is not as good as 32-bit. I can also add a lot about compiling speed and debugging in Delphi 64-bit but I'm too lazy to type all this. So I hope the 32-bit compiler stays with us for many years to come.

 

Bug part of my work is service applications for Windows Server and I ship all of them as 32-bit exes - speed and reliability is just so much better.

Too bad that 64 bit IDE cannot produce 32 bit exe, but I cannot agree about speed, can you show example or some benchmark about 30-40% faster?

From my micro benchmarks tests it's exactly the opposite and executed code is just faster in x64, however horribly much bigger exe size