PeterPanettone

OK, I get it. But then, why I don't get indirect units in the same way if I select a directly used unit node in the left tree: In this case, even the "Unit Uses" tab does not show any used units in "ToolsApi".pas, although it has a uses clause:

Thomas, what do you mean by "contains all units of the project"? When I select the root node "GExpertsRS103.dproj" on the left side then only the GX_* project units are displayed in the "Unit Uses" tab on the right side: ... and no indirectly used units are displayed in this tab.

Thomas, you are right. However, this is not a merged list without duplicates in the strict sense because in the following case ComCtrls is being listed twice: uPDFViewer,ComCtrls SkinDemoUtils,ComCtrls So, the exported list is certainly useful. But for my purpose, I need to remove the duplicates.

Thomas, that is an important addition, thank you very much! You wrote in your blog: There could be cases where the fallback is not evident because the map file creation has failed for some reason while the user believes the map file is being used because he has checked that option in the Options dialog. Therefore, I feel it would be better having a checkbox directly in the Grep Search dialog: "Indirectly used units" in the "Delphi Code Content Types" group-box: This checkbox would be automatically disabled in the case no map file exists so the user is AWARE that no indirectly used units (I call them implicit units) can be searched.

Thomas, I've built #2590. But I don't see where I can display and/or export a merged list of all used units in the whole project. The list created by "Export Used Units..." is the same as before. BTW, is there somewhere a possibility to see the current version/release number in the IDE, because both the old and the new show the same version number:

I like this idea.

Good point. Yes, different text and/or background colors for interface and implementation would be nice. The aim is to somehow indicate the scope of each found identifier. But then it would be logical to differentiate also between other scopes? What do you think?

Writing "implementation section" in each and every found item is useless and takes too much space on the list. One single implementation marking like in my example is enough to clearly see which found items are above the implementation keyword and which ones are below the implementation keyword, as there is maximally only ONE implementation keyword in a unit.

The "implementation" marking is much better visible and therefore more INTUITIVE.

Having such a flexible option IMO would be useful in EVERY case.

I have filed a new feature suggestion for MMX: The "Find Identifier" popup window should have an "implementation" marking: This would be very useful as it would allow seeing at a glance which identifiers are above or inside the implementation section!

I agree for very few cases. In most cases, the directly used units would be enough. Maybe an option (a checkbox) "Include indirectly used units" would be the optimal solution?

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: