MMX for Delphi 10.3 Rio

[PeterPanettone 158]

Thanks for the explanation!

 

Unfortunately, "Find Declaration" in such cases:

 

 

...mostly does not work. 

[Uwe Raabe 2059]

Let's take that as a sign that implementing this feature is probably far from easy.

[PeterPanettone 158]

Would such an approach be too simplistic?:

for each Unit in UsedUnits do
begin
  if Unit.Contains(AIdentifier.Name) then
    Result := Unit.Name;
end;

[Uwe Raabe 2059]

If Contains means a simple text search and given your example above, that would return the first unit where TButton is used or declared.

 

Actually, there exists something like that in MMX used for auto adding units to the uses clause when a specific type is used (see General Settings under Parsing). Unfortunately, in my opinion, that too often gives false results, because it relies on pre-scanned units and not resolving the units found inside the uses clauses.

[PeterPanettone 158]

1 hour ago, Uwe Raabe said:

If Contains means a simple text search and given your example above, that would return the first unit where TButton is used or declared

 

Obviously, it would be very naive using a simple text search in the implementation of *Contains*.

 

That proposed pseudo-code would need an intelligent implementation.

 

Maybe I should have written:

if Unit.Implements(AIdentifier.Name) then

... to make it more clear.

Edited January 3, 2019 by PeterPanettone

[dummzeuch 1506]

It would also have to start from the last unit in the uses clause and stop when it finds the first match.

[PeterPanettone 158]

2 minutes ago, dummzeuch said:

It would also have to start from the last unit in the uses clause and stop when it finds the first match.

Logically, it would have to stop when it finds the first match.

 

But I don't see the need to start from the last unit. How would you define the order of the units?

Edited January 3, 2019 by PeterPanettone

[dummzeuch 1506]

19 minutes ago, PeterPanettone said:

But I don't see the need to start from the last unit. How would you define the order of the units?

If there are multiple declarations of the same type (or variable or const or function or procedure) in different units, Delphi takes the last one it finds:

Unit a;
[...]
type
  TBla = integer;
[...]

Unit b;
[...]
type
  TBla = string;
[...]

Unit c;
[...]
uses
  a, b;

var
  x: TBla;
  [...]

Would mean that x is a string.

So, when searching for the relevant declaration, one must start at the end of the uses list:

Unit c;
[...]
uses
  a, b;

var
  x: b.TBla;
  [...]

 

[Fritzew 51]

Yes ist must be the last unit, but the real problem is the IDE not finding the correct Unit....... We should not need a third-party tool for
these kind of functionality. It should be work out of the Box, that's the reason for a IDE!!!

[PeterPanettone 158]

35 minutes ago, Fritzew said:

but the real problem is the IDE not finding the correct Unit....... We should not need a third-party tool for
these kind of functionality. It should be work out of the Box, that's the reason for a IDE!!!

2

Exactly. There should be an option "Add scope prefixes", that when inserting an object instance in the IDE Designer, for example when dragging a button object from the Tool Palette to the form, then the IDE should automatically insert this code:

type
  TformMain = class(TForm)
    btnGenerateCertificate: Vcl.StdCtrls.TButton;
    //etc.

The scope prefix is very important because it removes ambiguity and it adds clarity.

Edited January 3, 2019 by PeterPanettone

[PeterPanettone 158]

2 hours ago, dummzeuch said:

It would also have to start from the last unit in the uses clause and stop when it finds the first match.

Actually, to check for namespace ambiguity, it would be also useful to NOT stop at any match.

 

For example, an addon which checks for namespace ambiguity would traverse all type-identifiers in the source code and check whether any type identifier (at least those with no fully qualified namespace prefix) is implemented in more than one used unit.

 

That would be very useful, as type-ambiguity bugs can be very nasty.

[Uwe Raabe 2059]

1 hour ago, PeterPanettone said:

The scope prefix is very important because it removes ambiguity and it adds clarity.

Actually, I would hate reading such code. It is distracting and extends the amount to read with no real information gain. It's a TButton - I don't care where it is declared. If I want to know I use Code Insight.

 

6 minutes ago, PeterPanettone said:

For example, an addon which checks for namespace ambiguity would traverse all type-identifiers in the source code and check whether any type identifier (at least those with no fully qualified namespace prefix) is implemented in more than one used unit.

There already is such an AddIn and it is called Pascal Expert. The corresponding report is STWA2:

Quote

STWA2-Ambiguous unit references

Top  Previous  Next

Ambiguous unit references (STWA2)   This sections lists identifiers with ambiguous unit references. Consider this example:     What will be the output from the program? In this case, it will be “Goodbye”, because the last unit listed in the uses clause will have precedence.   The reference to TheValue is ambiguous or unclear, so it will be listed in this report section. Consider what happens if originally only unit “A” was listed in the uses clause. Then the output would be “Hello”. If then maybe another programmer without any sense of danger will add “B” to the uses clause, the output will be changed.   You should prefix the reference, like “B.TheValue”, to avoid any uncertainty.

 

Edited January 3, 2019 by Uwe Raabe

[PeterPanettone 158]

24 minutes ago, Uwe Raabe said:

There already is such an AddIn and it is called Pascal Expert. The corresponding report is STWA2:

 

 

Thanks for the information!

 

@Pascal Expert wrote: You should prefix the reference, like “B.TheValue”, to avoid any uncertainty.

 

Good advice!

Edited January 3, 2019 by PeterPanettone

[Stregor 0]

Hello.

I'm using Rio 10.3.2 and newest MMX 15.x. My project is quite big - about 350 .dfm and about 700 .pas

I observe dramatically reduced speed of using "Open Unit" dialog (Ctrl+F12) and "Edit Entity" (Ctrl+E). From click Ctrl+E to show dialog - especially when i want edit entire class or interface, not class member - sometime i must wait a minutes! Yesterday for about 35 minutes of waiting i must kill Delphi. 

 

First i blamed Rio, but when i uninstall MMX 15 and go back to MMX 14.x then speed return to normal. Still not lighting speed but acceptable :)

 

P.S. in Delphi Seattle is the same problem with MMX speed.

[Uwe Raabe 2059]

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

[Uwe Raabe 2059]

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,

[ULIK 16]

Uwe,

 

here are some steps with that I can reproduce this performance problem on XE 10.2.3 every time.

• close any project on IDE
• close IDE
• start IDE again
• create a new VCL app  (you should now be on [unmodified] standard layout)
• open MMX Explorer (by menu)
• select TForm1 entry
• press Ctrl+P (add new property)

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

 

The key point is this: you have to restart the IDE. Then only the first time the dialog opens it will show that delay.

 

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.

Edited September 12, 2019 by ULIK
second note

[Uwe Raabe 2059]

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.

[ULIK 16]

Are you sure that this path is used? I deleted both MMX-History.xml as well as BDS19_known_modules.xml from that path (after closing the IDE) and restarting IDE, I can still reproduce this and the dropdown still shows that enormous data.

I have installed MMX to be available only for me.

 

[Uwe Raabe 2059]

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?

[ULIK 16]

Yes, Pre-parse editor files is activated:

 

 

But I think I found the problem: as soon as 'Check Packages' is disabled, I can't reproduce it any more. I played with that four options: disable all 4 and everything is fast, then activate 'Check Packages' only, restart IDE and it slows down to 10 seconds.

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)

[Uwe Raabe 2059]

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?

[Stregor 0]

Hello Uwe.

I was tested 15.x a moment ago, and:

Ctrl+E when i edit entire class TFoo - about 50 sec with "Check Packages" checked (seems no matter first or next use, but i did not measure it with a stopwatch)

Ctrl+E when i edit entire class TFoo - about 1 sec with "Check Packages" unchecked

 

14.x

Ctrl+E when i edit entire class TFoo - First use - 14 sec,  second and next uses - 4-6 sec with "Check Packages" checked

Ctrl+E when i edit entire class TFoo - about 1 sec with "Check Packages" unchecked

[Uwe Raabe 2059]

@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.

[Jacek Laskowski 57]

Every now and then, irregularly, MMX kills my IDE (10.3.2).

The Check Packages option is turned off - thanks to this hangs are much less frequent, but they have not disappeared.

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