Uwe Raabe

Is this VCL or FMX? Which target platform? Can you provide a minimal example showing that?

I actually rate this as an advantage. Otherwise it would not be much different to the old DUnit.

I am not sure if the quote is actually the intended one, as Thomas description is not related to the clipboard at all. In case you are referring to the MMX solution, make sure that you copy the interface (not its methods) from the contents list of the MMX Code Explorer window and paste it into the members list of the target class.

You may also have a look into CodeSite, which allows similar things in a more convenient way. The Express version can be installed via GetIt,

Thanks, will check that. Btw, I have also seen this issue from time to time and TaskManager indicates some threads waiting for I/O completion. So that may indeed be related.

As these problems are hard to track down, I need to dedicate some time to that fix. Unfortunately I am not able to spend a significant amount of time on MMX in the moment, so it may take a while for the V15 beta to proceed.

I understand that. On the other hand you get a problem with other parts of the RTL (f.i. THTTPClient) which obviously cannot make use of OTL to achieve some multi-threading features like async execution. If OTL is the choice for multi-threading one has to write its own async functionality for these parts based on OTL, which might turn out pretty time consuming (and also error prone). A reliable RTL with all of its parts working together out of the box would beat any manually assembled set of third party libs by magnitude. I fully agree with you regarding the lack of quality control, though.

I would prefer when PPL would be fixed and stabilized instead of not being used at all. There is a couple of functionality in Delphi that relies on PPL and that would need to be reinvented where another external library is used. The lack of manpower dedicated to this part of the RTL (and a lot of others) is a real drawback. I wish Embarcadero would allow more participation from the community or at least all the MVPs that already offered their help in these areas. Another option would be to open source the standard libraries and accept pull requests, but that seems to be only at the edge of their radar - if at all.

If things were always done right in the first place neither the term bug nor the term workaround would exist.

That is only a workaround until the dialog allows setting it directly. The mentioned option is a last resort to tweak the command line parameters given to the compiler.

In Project Options - Delphi-Compiler - Compiling add the following value to Additional options to pass to the compiler: -W^UNKNOWN_CUSTOM_ATTRIBUTE

Yes, my comment to Marcos post remained unheard. We should create a separate QP entry for that.

@Stregor, @ULIK thanks! That narrows down the research area a lot. The next beta will emit some data to the event log to allow some better analysis.

Yes, that is true. The package info related to the Check Packages option is built on first use (probably to reduce startup time). It scans all packages loaded in the IDE and adds all classes and interfaces from each package containing at least one component. Can all people hit by this problem please check if it can be solved by disabling Check Packages?

You should be able to check this inspecting the last change time of that file. Are by any chance all these source files added to the project and do you have Pre-parse Project Files enabled in the MMX General settings?

Less than a second here. Yes, that may be the cause. You can try to rename the module cache file: "%LOCALAPPDATA%\Raabe Software\MMX Code Explorer\15.0\BDS19_known_modules.xml" and see if this reduces the time to wait.

As I have difficulties to reproduce the above mentioned performance drops at my side, I would be grateful if someone could provide a project showing this behavior. I am willing to sign an NDA if necessary,

I am already investigating that. Unfortunately I cannot reliably reproduce it here.

Indeed! After trying several other approaches I reverted my build machine back to 10.3.1 to provide a compatible version. Believe me, I am not amused - to say the least.

For an IDE package to work in Delphi 10.3, 10.3.1 and 10.3.2 it has to be compiled with 10.3 or 10.3.1 in the first place. The compatibility patch is needed to make such an application work with 10.3.2 (actually the patch is meant for 10.3.2 installations only). There is no way to make a package compiled with 10.3.2 work with 10.3 and 10.3.1. This case is a bad combination of first breaking compatibility by accident and then refuse to fix it because that would break some other compatibility.

Highlight the text with the mouse and click on the then appearing Quote bubble:

AFAIK, IndexDefs (as well as FieldDefs) are stored in the DFM when StoreDefs is True, but I guess they are not part of the data file.

There is a new beta available. Changing the version number to 15 resembles not only the completely different new look due to theme support and new icons, but also the internal changes necessary to make all this work. Hopefully I didn’t break too much.

OK, I found why I thought the problem to be fixed: It happens only under some complex conditions which were not always satisfied in my test configuration.

Indeed. Not sure what scenario I tested then. I am also wondering what Unit Dependency Analyzer has to do with it.