Uwe Raabe

 I often have different optset files containing unit search path entries. Usually I separate them by library name.

F.i. there is one optset for TMS Scripter or GLScene, where several folders have to be added to the search path. As my folder layout for projects is consistent, the search path for each library is the same for each project. Thus I only have to add that optset to each project (only the first one, the others with drag'n'drop) to add the necessary folders to the project search path. As a gimmick I can see immediately which libraries a project depends on.

This is als pretty convenient when the projects inside a project group share a couple of local folders in their search path. Using an optset for that makes changing the search path for all projects at once just a breeze.

Unfortunately FinalBuilder is not able to resolve those optset references. Therefore I have written a small program doing that, which is called immediately before the compile action.

Regarding RSP-14723: Indeed, optset references are not removed from the dproj. As that is not very common in my workflow I usually fix this by editing the dproj manually.

1 hour ago, PeterPanettone said:

Why are there no Win64 compiler versions listed

Basically because there has been no need to implement it yet.

The compiler version merely sets the default conditional defines (like VER320) related to the compiler, but those can be extended by yourself in that same dialog. Also, only the uses clauses are parsed for dependencies, so most of the code is ignored anyway. 

What differences in the dependency results do you get with the plain Win32 compiler setting compared to Win64?

Another advantage of actions and action lists is that they can reside on a datamodule, which can be used in a VCL and a FMX application. Thus the same action logic can be used, which might have to be duplicated otherwise.

If it is related to TCustomEdit executes VK_DELETE while observer forbids it should be fixed in 10.3.2

Selective Debugging allows to select the debug DCUs on a per unit basis. This doesn't affect the content of the call stack.

Honestly, I doubt that removing this information from the call stack is of any benefit at all. In fact it would camouflage the actual program flow rendering the call stack next to useless.

I often get the impression that our computers already established some form of artificial intelligence, but for some unknown reason it usually turns out to be a mean one.

Perhaps that big company is run by the fathers of those Tom, Dick an Harry and they trust their kids more than the experts?

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

5 hours ago, dummzeuch said:

Unfortunately it supports only Delphi 2010 and later.

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

10 minutes ago, A.M. Hoornweg said:

Does this support copying to the clipboard?  In Delphi XE it doesn't.

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.

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.