PeterPanettone

Sorry for making the impression of "ranting". It was REALLY meant as objective and constructive feedback. Discussions can have ramifications. Peace! "colors, images and image sizes" are not irrelevant. They are an (often overlooked) essential part of the user interface and thus of the program's functionality in the wider sense. Do you want me to file a feature request for this?

There is another one which seems to be the most obvious: When migrating a project (maybe a legacy project or a project received from another developer) it is important to have a complete overview of which units are used in the whole project.

YOU KNOW that the two toolbars each have a different functionality scope, but for the USER this is not visually evident. There should be a visual distinction between the two toolbars. BTW, the "Print" button could be easily overlooked as it has a grey color: , so it seems to be a disabled button. Enabled buttons should be colored to distinguish them from disabled buttons. Also, why using a "Printer" image for a REPORT functionality? This is clearly misleading. And why are the buttons so tiny? For example, these two buttons cannot be visually distinguished:

Is this logical? Because the Print dialog does not mention this. One would expect that the report outputs the same list as shown in the pane.

So the Print button in the Unit Dependency Analyzer will become my preferred workaround solution. I just need to write a small tool to format the list in the way I need it (as a uses clause list).

The Print feature seems to have a bug: With the only Show not found units filter switch activated, also the Show Found units items are output. Even with no filters activated, all items are output.

Here is the list: There is no way to copy or save the list.

The Unit Dependency Analyzer shows the used units per project unit. But not a merged list for the whole project.

The MMX Module Analyzer has the same problem: It lists BOTH explicit and implicit units.

I have this line in the map file: 0001:0033B2E8 000073E8 C=CODE S=.text G=(none) M=Vcl.Buttons ACBP=A9 But the unit Vcl.Buttons is not EXPLICITLY inside a uses clause inside my project. So I suppose the unit Vcl.Buttons is IMPLICITLY inside a used unit. How to differentiate between explicit and implicit units?

Thank you for your idea! The map file for my project is 93 MB. For what should I look?

That is useful only when using one of these options: Otherwise, attempting to load the associated form file can interfere with the current project! So, the MMX Indexer result-list should automatically load the result file in the IDE on mouse-click ONLY if the result-file is part of the current project (or if the result-file is already opened in the IDE). This would be much smarter! Additionally, when using the Root paths option or one of these options: ...then this option in most cases is useless: ...because the content of the Library path or the Browsing path does not change that often. In this case (if the Rebuild option is unchecked) it would be far more intelligent to not erase the index between IDE sessions or to rebuild the index only if a change has been detected in one of these paths! So a separate dockable context preview panel for the MMX Indexer IMO would be very useful.

That is also a great search tool with flexible options for the search locations: However, it lacks the invaluable CONTEXT PREVIEW of the GExperts Grep Search: ...which can be configured here: The MMX Indexer Search loads the result file in the IDE by just left-single-clicking the result line which for me is not good because it also attempts to load the associated form file (if it has one). It should definitely have a preview pane like Grep Search!

Jacek, thank you for pointing that out. I am using this feature all the time. It is INVALUABLE for checking whether there are other instances of the current identifier under the cursor nearby. On a wider scope, I use the GExperts Grep Search, as it can optionally even search an identifier in ALL FILES inside a project group!

Done. Thank you!

Yes, I mean without moving the cursor.

I have posted this feature request ticket in the GExperts ticket list: https://sourceforge.net/p/gexperts/feature-requests/56/ This is an idea for a new GExperts module: In the Delphi IDE, the content of the Structure panel changes according to whether the code editor or the form design editor is active (which IMO is a legacy hangover from the Delphi stone age when computer monitors generally had the size of a postage stamp, hence the space-saving dual-use of the Structure panel). In my opinion and for me, the Code Explorer items which are visible when the IDE's code editor is active are COMPLETELY USELESS, as the FREE MMX CODE EXPLORER has much better functionality. So this new GExperts module should optionally hide the Code Explorer items in the Structure panel when the IDE's code editor is active. Instead, the components of the form structure should be PERMANENTLY visible, even when the code editor is active! Having to hit the F12 key while coding in the code editor only for selecting a component in the Structure panel and then viewing/editing properties of this component in the Object Inspector is a useless waste of time!

By Trial & Error, I have found this undocumented feature in the Delphi 10.3.1 IDE: When the form-design editor is detached from the IDE: ...then the Components Structure View is permanently visible, even when the code editor is active!: Can anyone confirm this? So the above problem seems to be solved.

I have found Embarcadero to be extraordinarily reluctant when it comes to cut or change old pigtails from the Delphi IDE.

I have posted this feature request ticket in the GExperts ticket list: https://sourceforge.net/p/gexperts/feature-requests/55/ GExpertsGrep.exe has a fantastic feature: It can be started on the command line and pass a directory parameter to it. For example, this command line: "C:\Program Files (x86)\GExperts for RAD Studio 10.3\GExpertsGrep.exe" C:\COMP\_CNScripts ...opens this GExperts Grep Search window on my computer: When you double-click on a search result line, then the IDE associated with the respective file type (e.g. .pas) is being automatically opened and the file loaded in the IDE! The only issue is that the respective source code location of the result is not automatically shown in the IDE source code editor. With this issue solved it would be perfect! Also, another feature would be very helpful: If no IDE is opened the respective result file should be loaded into a pre-configured text editor (of course showing the respective result location line and column and select the search term result).

So my SUGGESTION is to add this intelligence to GExperts Grep Search: • If any IDE is open then open the result file in that IDE. (I am not sure whether it is possible to open a source file at a specific location by specifying command-line parameters). • If no IDE is open AND a text editor has been pre-configured in GExperts Grep Search then the result file should be opened in that text editor.

For what do you need the registry entry? That's how I do it in my programs: JclShell.ShellExecEx('mailto:support@mmx-delphi.de'); There is no need for a registry entry.

I have discovered another bug: On the About page, when clicking on the mailto-label, no email is being created: Obviously, a wrong method is used: With a simple Winapi ShellExec it should work. I have sent a bug report.

Your guess is correct. I will send a bug report. If you want I can write a CLI for your Final Build process for you which flattens the version number into the image.

Now I have looked closer and I have discovered an almost completely invisible version number. This is in Delphi 10.3 Rio: Is this due to a bug in the Delphi 10.3 Rio IDE or is this a bug in MMX?