PeterPanettone

Thanks for the information! @Pascal Expert wrote: You should prefix the reference, like “B.TheValue”, to avoid any uncertainty. Good advice!

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.

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.

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?

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.

Would such an approach be too simplistic?: for each Unit in UsedUnits do begin if Unit.Contains(AIdentifier.Name) then Result := Unit.Name; end;

Thanks for the explanation! Unfortunately, "Find Declaration" in such cases: ...mostly does not work.

So would you please consider adding this very useful functionality? I have made the experience that "Find declaration" for some identifiers works better if the identifier has this kind of specification.

Thanks for "Format Uses Clause" command! Is there a similar command to achieve the following: Turn this: type TformMain = class(TForm) btnGenerateCertificate: TButton; //etc. Into this: type TformMain = class(TForm) btnGenerateCertificate: Vcl.StdCtrls.TButton; //etc.

Thank you! Installation in RIO worked fine. Are there any IDIOT-PROOF STEP-BY-STEP INSTRUCTIONS FOR USE?

Thank you, this is a very welcome addition, as some web pages look very ugly in the Welcome Page!

The IDE Desktop Layouts DropDown is broken in my 10.3 IDE.

I will try it.

Problem can easily be solved by Embarcadero. Ergo: Embarcadero sucks.

As I already said, this is not possible.

Of course it is OK. I just pointed to the possibility to have two different toolbars.

Many users have a big screen and they NEED to work with a scale factor of e.g. 125% otherwise they would not be able to read any text in a word processor. Shouldn't a professional software be able to adapt to different scaling factors? Imagine Microsoft would tell their customers: "Microsoft Word is optimized for a scale factor of 100 %". They would lose 75% of their customers.

This is a misunderstanding: Not on the NavigationToolbar, as this is a Code Editor command. You can have e.g. the GExperts toolbar on the left side and the CnWizards toolbar on top:

Is this a scaling bug? How can it be resolved?

No, please add these commands as editor-toolbar-icons. I use them a lot.

Yes, this drop-down panel is outside of my IDE window and is attached to the upper edge of my screen because I have a desktop toolbar attached to the upper edge of my screen. It should be inside the IDE window and attached to the main toolbar or to the IDE title bar. Obviously this dropdown toolbar thinks: "The IDE window is maximized, so I will attach myself to the upper edge of the screen, so it looks as I am attached to the IDE title bar". But the dropdown toolbar does not realize that even when the IDE window is maximized, this does not necessarily mean that the IDE window title bar is attached at the upper edge of the screen. Which on my desktop is not the case because the desktop toolbar is between ths upper edge of the screen and the IDE window title bar!

Thank you for MMX Code Explorer! This is such a great addition to Delphi! Have you compiled the MMX dialog form with the Scaled property set to True? If yes, maybe this could be the cause for the dialog font size being too large on my big screen? (With the system-font set to 125%): What do you think?

Thanks, Uwe. But wouldn't it be easier to CONSTRAIN the labels and checkbox captions to a specific pixel width?

Thanks, Uwe. However, this is on my primary monitor. Here is another example: I am on Windows 7 x64 SP1. I do not have Windows 10 to test it on Windows 10. Does it look better on Windows 10?