PeterPanettone

6 minutes ago, Uwe Raabe said:

That Lock Toolbar option is probably not standard, is it?

I am not sure what you mean.

9 minutes ago, Uwe Raabe said:

Well, we still have IDE Insight. Press F6 or Strg-<dot> and enter navi: You will get a list where one element is the mentioned one (it is the last one in my case). Select and press enter and you are at the right place.

 

 

And how do I know that the name of this toolbar is "Navigation Toolbar"? This makes me think of the German fairytale "Rumpelstilzchen": "Oh wie gut, dass niemand weiß, dass ich Navigation Toolbar heiß!"

BTW, the caption "Lock Toolbar" is misleading. It should be "Lock Toolbars" instead because it affects all IDE toolbars.

The Delphi IDE has a "Lock Toolbar" popup menu option:

However, even when this option is activated then the MMX toolbars are still movable:

Wouldn't it be better if the MMX toolbars would be locked too in this case?

Uwe, thank you very much, this was so annoying!

But this IMO is also a good example of a bad user interface. Imagine this situation: To turn on/off the light in the living room you would have to go to the bathroom because the light switch for the living room is in the bathroom. Obviously, the better solution would be to have the light switch for the living room directly in the living room!

In Delphi 10.3.1 Rio, I have the Form Designer detached from the main IDE window:

When the Code Editor in the main IDE window is focused, I have these 3 toolbars above the Code Editor:

The toolbars (2) and (3) are from MMX.

Toolbar (1) SUPPOSEDLY is a native toolbar from the Delphi IDE. But it seems not to be listed in the Customize list of toolbars? I have not found any way to hide this toolbar. How can I hide it?

Why do I want to hide it? First, its functionality is already contained in MMX, so this toolbar is a waste of space. There is also this problem:

When I select the form in the detached Form Designer then this toolbar (1) gets automatically hidden. When I then reselect the Code Editor in the main Delphi IDE window then this toolbar (1) automatically reappears which causes considerable flickering, and because of this flickering, a portion of code in the code editor gets selected which is VERY ANNOYING!

So how can I HIDE this toolbar (1)?

3 hours ago, dummzeuch said:

... and then you switch to the "indirect dependencies" tab and ... ?

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:

3 hours ago, dummzeuch said:

And the list for the project (root node in the tree) contains all units of the project.

 

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.

9 minutes ago, dummzeuch said:

That list already contained all used units, including those indirectly used.

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:

Quote

If there is no MAP file, it falls back to the original method of searching files listed in the DPR file.

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.

17 hours ago, dummzeuch said:

Done.

 

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:

24 minutes ago, Uwe Raabe said:

As I said: those two icons are already used elsewhere to mark the interface and implementation section and should thus be immediately recognized. Why should I introduce alternative icons here?

I like this idea.

1 hour ago, Uwe Raabe said:

How is this supposed to work when the number of visible lines is less than the number of lines in the interface/implementation section? A simple marker line (I would suggest something like a plain horizontal line to avoid wasting a full text line) will scroll out of view.

I was thinking of different text and/or background colors for interface and implementation, but the styling system doesn't really like custom coloring. It often looks pretty poor in at least one of the standard themes. Perhaps we can adopt some of the syntax highlighter settings? This would honor the fact that the editor can have a different color scheme than the IDE itself.

1

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?

26 minutes ago, Dinar said:

I think Parnassus Bookmarks editor window like would be more nice implementation. Just instead of bookmarks, there will be displayed the founded identifier

1

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.

3 minutes ago, FredS said:

 

Well, or we could just continue to use the preceding class name as the indicator...

procedure DoStuff; // interface

procedure TMyStuff.DoStuff; // implementation

 

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

16 minutes ago, dummzeuch said:

For the user: yes, for the programmer: no.

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!

13 minutes ago, dummzeuch said:

For which again you would want to get a complete list, including those units indirectly used.

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?

29 minutes ago, dummzeuch said:

I can only think of a few uses for such a list:

• Check if a unit is added that should not (e.g. it is being phased out / deprecated)
• Get a list of 3rd party components to e.g. add to an about box (But that is better done at runtime.)
• Search all used units for some string (What GExperts Grep now does and the GExperts Open File has been doing for a while)

 

 

 

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.

11 hours ago, Uwe Raabe said:

The report is not bound to the list and takes the complete scan result as output. Its position in the main toolbar instead of the list toolbar even suggests that it is not bound to the list. (I am just realizing that this may not be true for the official version, so I'll add a screenshot of the development version).

 

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:

5 minutes ago, Uwe Raabe said:

Not a bug - simply as designed!

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.