Uwe Raabe

i get the same error message with GetIt, but that is not under my contol. The standalone installer should do, but leaves GetIt unaffected.

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.

Even a TMainMenu is drawn according to the current VCL style. A simple test confirms that. 

So, what class type has the form and is that class registered to the ThemingServices?

3 minutes ago, DelphiUdIT said:

For me is working, every time I insert or delete a char (with backspace or canc) the list is updated.

Same here.

Since the announcement in the See What's Coming in RAD Studio 13 Florence webinar last Wednesday, where MMX Code Explorer was promoted as a replacement for the removed refactoring in Delphi, there have been more than 1200 downloads. With this number it is no surprise when some people encounter problems installing or using it. This is a short list of things that happened and hints how to avoid these problems. I expect this list to be extended over the next couple of days.

• Some people get a virus warning when downloading the zip file. This is the MD5 hash of MMX_Setup_16_0_8_59.zip to verify that your copy is the original one: c24ef7eb0d073a97541bd8e11494cdad
• Always use the recommended Install for me only option! The admin mode Install for all users is heavily broken and can lead to problems when uninstalling. If multiple users are sharing the same Delphi installation each one has to install its own copy of MMX Code Explorer.
• Don't set your Startup Desktop to <none>. While this worked in previous versions, the new V16 doesn't like it. The issue will be investigated.

40 minutes ago, dummzeuch said:

What kind of strange formatting might that be?

I was just about asking the same 

3 minutes ago, pyscripter said:

Actually I am getting the hint with both Win32/Win64  (32 bit IDE) and a DEBUG configuration.

As I am getting just the opposite, there must be some difference with our tests.

6 hours ago, dummzeuch said:

They gave the version the number 13 and you suppose they jump in the BDS version from 23 to 37 in order to avoid 13?

Indeed, 24 would have been expected, bat wasn't 24 some sort of secret Illuminati number? And 24 + 13 = 37 😲

I made some tests. In all cases Hints are enabled.

Targets: Win32/Win64

DEBUG, Assertions on : no hint

DEBUG, Assertions off : no hint

RELEASE, Assertions on : hint

RELEASE, Assertions off : No hint

The behavior with RELEASE seems fine, but why is it different with DEBUG?

I am also a Ctrl+D guy, but usually only for the current selection - and, yes, I will have also have to find a replacement, at least temporarily.

Currently I am inclined to use the GExperts Formatter, as it is based on the old DelForExp by Egbert van Nes, which I had been used to quite a long time in the past.

The DLLs are signed and MMX_Setup.exe is also signed. What else can I do? 😭

6 minutes ago, dwrbudr said:

No refactoring is a showstopper for me to use Delphi 13.0.

Can you say what refactoring you are actually using?

Yep, that sounds like a valid scenario for triggering the problem.

I also cannot explain why the code is as it is - I just kept it as it was when I took over.

Do you have a suggestion which window handle I could use as the owner window?

9 hours ago, Attila Kovacs said:

Does the code formatter support any of the new syntaxes, or has it been removed completely? 

As part of the Modelling package it has been removed completely, too.

The message is expected. It basically asks if it should copy existing V15 settings to V16.

I assume the 15.0.7.52 is a typo and should read 16.0.7.52 and refers to the latest beta version?

That didn't make use of separate V16 settings and silently used the V15 ones, so that message is not triggered.

Back to the actual problem. As there were quite a couple of downloads and installations since the webinar and I'm not getting tons of complaints like the above, there must be something in your environment triggering that.

The code responsible for that message is:

    if MessageBox(0, PChar(Format('Use MMX Code Explorer V%d settings?', [MidexVersion - 1])),
                  'MMX Code Explorer', MB_YESNO or MB_ICONQUESTION or MB_TASKMODAL) <> IDYES then Exit;

Because of MB_TASKMODAL any windows shown by other threads can be shown and worked with, so I guess some other thread is showing a window not visible to us in a way that blocks input to the MMX message.

The one thing visible on the screenshot is GExperts for Delphi 12  . Just to rule things out, can you please try without that?

3 hours ago, mvanrijnen said:

with a big project

Define big.

There have been more than 500 downloads since the webinar yesterday and this is the first complaint. 🤔

1 hour ago, Tommi Prami said:

some kind of how to/best practises etc video would be super fgood thing.

IIRC, Ian Barker is on for something like that. Not sure about the content and how much is covered. I will talk to him about that next week when meeting in person.

There is a video linked to from the MMX website, but that is in German. There are plans to do something like this in English using a more recent Delphi and MMX version, but the biggest problem is to find some time.

While there also will be a workshop next Wednesday (also in German), there are plans to offer online workshops in English and German. Unfortunately there is no time frame for that.

27 minutes ago, PeterPanettone said:

No BUG FIXES?

Where did you read that?

New features and customer reported issues fixed in RAD Studio 13.0

On 9/7/2025 at 8:34 PM, david berneda said:

I had an issue with a test project that lost the options, this would never happened if something like PASS existed.

This sounds as if you want a fallback for the case when parts of the dproj file get lost.

At the end, implementing your proposal will override the settings in the dproj file and make it (at least partly) obsolete. Especially the different Build Configurations and platform settings are almost meaningless when such options are placed inside the sources.

I cant' help, but to me it looks like you want to solve a completely different problem. If I get it right, it is already solved by using version control.

16 minutes ago, Javier Tarí said:

Crazy, isn't it?

I would rather call it diversity.

What about units that change the passed directive values?

33 minutes ago, david berneda said:

Potential versionitis issues if A and B where compiled with a different version of the shared unit/package.

6 hours ago, david berneda said:

both units should share a living instance.

What about that living instance? Where is it declared and where does it live? Will interchanging it survive being compiled with different versions of A and B? Even being compiled with different compiler settings may cause a crash.

8 hours ago, Dave Novo said:

However, it seems impossible for me to browse other people's issues on this new portal so not sure anyone else can see it. 

I cannot see your new entry either. To make an issue visible to others one should leave the Share with at Share with Embarcadero Customers.

You should be able to change that even for your exiting issues to add this group in case it is missing.