Uwe Raabe

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

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? 😭

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?

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?

Define big.

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

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.

Where did you read that? New features and customer reported issues fixed in RAD Studio 13.0

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.

I would rather call it diversity.

What about units that change the passed directive values?

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.

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.

You don't even have to provide that function as long as the strings matches the enum identifiers: s := 'three'; case TRttiEnumerationType<TMyStrings>.GetValue(s) of zero: writeln('zero'); one: writeln('one'); two: writeln('two'); three: writeln('three'); four: writeln('four'); end; Or if you prefer a more readable approach: type TMyStrings = (zero, one, two, three, four); TMyStringsHelper = record helper for TMyStrings public class function FromString(const AString: string): TMyStrings; static; end; class function TMyStringsHelper.FromString(const AString: string): TMyStrings; begin Result := TRttiEnumerationType.GetValue<TMyStrings>(AString); end; ... var s := 'three'; case TMyStrings.FromString(s) of zero: writeln('zero'); one: writeln('one'); two: writeln('two'); three: writeln('three'); four: writeln('four'); else Writeln('What?'); end;

Isn't that what Attach to process is for?

The point is not to prove that it works or that it doesn't, but to find out when it works and when not.

That crashes when Foo = nil and Short-Circuit Boolean Evaluation is off.

As mentioned elsewhere, you need to show more code that is before the function. The function code is correct, it is something before it that makes the compiler unhappy.

As the error report mentions a missing radconsole subfolder in that URL, it may as well be an error in the sources affecting all target platforms.