Jump to content
Uwe Raabe

MMX for Delphi 10.3 Rio

Recommended Posts

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

Share this post


Link to post

Would such an approach be too simplistic?:

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

Share this post


Link to post

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.

Share this post


Link to post
Posted (edited)
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 by PeterPanettone

Share this post


Link to post

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

Share this post


Link to post
Posted (edited)
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 by PeterPanettone

Share this post


Link to post
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;
  [...]

 

Share this post


Link to post

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!!!

  • Like 4

Share this post


Link to post
Posted (edited)
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 by PeterPanettone

Share this post


Link to post
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.

Share this post


Link to post
Posted (edited)
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:

 

image.png.28e12ad4b3f2fe7471e6ba4a18990ae2.png

 

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 by Uwe Raabe
  • Like 1

Share this post


Link to post
Posted (edited)
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 by PeterPanettone

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

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,

Share this post


Link to post

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 by ULIK
second note

Share this post


Link to post
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.

Share this post


Link to post

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.

 

Share this post


Link to post

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?

Share this post


Link to post

Yes, Pre-parse editor files is activated:

 

image.png.e3b7c0abb3508c91e39a377e49bf76ef.png

 

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)

Share this post


Link to post
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?

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

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.

 

vps_2019_10.04_01.thumb.png.09aff5da3c5e9fb0b33a0be5782fb1f1.png

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×