Uwe Raabe

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.

6 hours ago, Jacek Laskowski said:

I am still using MMX version 15 and waiting for a fix.

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.

3 hours ago, Stefan Glienke said:

With a library like OTL you don't need to upgrade your entire IDE to get some bugfix.

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.

47 minutes ago, Dalija Prasnikar said:

If the things were done right in the first place we would not need workarounds.

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

4 minutes ago, Dalija Prasnikar said:

Some warnings can be setup at one place, other in another.

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

7 minutes ago, Dalija Prasnikar said:

according to that there is supposed to be new warning so current behavior is fine, but I cannot see it nor turn it on. (except with compiler directives) 

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.

54 minutes ago, ULIK said:

Could it be that this information is collected only once at first use in IDE but not persisted (at least I did not found any file related to it)

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?

27 minutes ago, ULIK said:

Now I have to wait for about 10 seconds until the dialog opens.

Less than a second here.

27 minutes ago, ULIK said:

Just a guess: the dropdown list of the types: mine here contains several thousand entries (having heavy use of DexExpress library). Maybe the loading of that dropdown list slows the first start of the dialog.

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.

8 hours ago, Ian Branch said:

How do you get the individual quote sections into the reply please?

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.

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.

1 hour ago, David Heffernan said:

just looked tlat the documentation and it explains it all. You have to delete the sub keys.

Seems like the docs are mistaken here. The source code is more reliable and shows that subkeys are internally deleted.

55 minutes ago, dummzeuch said:

(Especially when removing the divide by cnt.)

ArcTan2 produces the same result when both of its parameters are multiplied with the same factor. Thus dividing both by cnt before calling ArcTan2  has no influence on the result.

In addition, ArcTan2 is pretty well capable of handling some special values like c = 0 (at least in non-ancient Delphi versions). There is no need to catch this case in advance.

This is a quote from Knuth's C adaptation of the original Adventure game by Will Crowther:

Quote

By the way, if you don't like goto statements, don't read this. (And don't read any other programs that simulate multistate systems.) 

Unfortunately some companies insist on having their corporate styling being reflected in their applications. Just because some colors are different from the Windows standard doesn't mean that one needs to learn how to use that UI. That is more related to uncommon handling of TAB vw. ENTER keys or the misuse of well known shortcuts.

Looks like this issue: Bug In popupMenu with VCL Style - fixed in 10.3.2