PeterPanettone

I have no "moon icon" in the IDE titlebar. Only after moving the IDE window with the mouse the titlebar controls become visible: Why does Embarcadero HIDE important commands in spooky places? That would be the same as a car manufacturer hiding the hand brake in the car trunk.

This is my configuration: Main Monitor: Monitor 1: LG ULTRAWIDE(38UC99)(Display Port) (3840 x 1600 pixel) (87 x 37 cm) Second monitor: Monitor 2: PHL BDM3270 (1440 x 2560 pixel) (71 x 40 cm)

It seems that maybe the list of items is being rebuilt each time a search is performed...?

In the Delphi 10.3 Rio IDE, where is the Save Desktop... menu item? I have not found it in the View -> Desktops submenu:

Hello, when I edit the property of TForm.Caption... in the Object Inspector: ...then this dialog appears: I assume that this is the JEDI StringList property Editor (because of the "J" icon)? Is there an easy way to disable just the Jedi property editors? BTW: A property editors Manager for Object Inspector would be very nice!

When trying to install ...\Delphi-Shortcut-Finder\Packages\XE8\nick.toolsapi.shortcut.DelphiShortcutFinder.dpk in Delphi 10.1 Berlin I got these compiler errors: [dcc32 Error] nick.shortcut.frame.KnownShortcuts.pas(143): E2003 Undeclared identifier: 'HintAnimation' [dcc32 Error] nick.shortcut.frame.KnownShortcuts.pas(143): E2003 Undeclared identifier: 'hatFade' [dcc32 Fatal Error] nick.shortcut.core.KnownShortcutsRegistration.pas(20): F2063 Could not compile used unit 'nick.shortcut.frame.KnownShortcuts.pas' This is the list of the package folders: XE XE2 XE3 XE4 XE5 XE6 XE7 XE8

I just wanted to say a public BIG THANKS to Mr. Fierens from TMS for his amazing and outstanding support: Today (which is a SUNDAY) I mailed him the description of a small bug. ONE HOUR LATER I got the bug fix attached as source code file in the mail. I never had a product (TMS ALL ACCESS) with such outstanding support quality!

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.