PeterPanettone

Remy, with your hints, it is now partially working: procedure TPopupListEx.WndProc(var Message: TMessage); var mii: MENUITEMINFO; begin inherited; if (Message.Msg = WM_ENTERMENULOOP) and (Message.WParam = 1) then begin // customize pmTest items as needed... ZeroMemory(@mii, sizeof(mii)); mii.cbSize := sizeof(mii); mii.fMask := MIIM_STATE; mii.fState := MFS_HILITE; Winapi.Windows.SetMenuItemInfoW(Form1.pmTest.Handle, 1, True, mii); end; end; Now, when I show the popup menu the first time, the menu item with index 1 is highlighted: But then, when I hover the mouse over the first menu item, BOTH menu-items are highlighted: Instead, the second menu-item should become un-highlighted when the first menu-item becomes highlighted. Why this is not the case? Only when I hover the mouse over the second menu-item and then back to the first menu item, the second menu-item becomes un-highlighted: So I repost here the changed source-code, so everybody can see how the code looks in detail: StickyPopupMenuSimulation_2.zip

I want to either expand the functionality of the Get Component Names GExpert to somehow include the CLASSNAME of the selected component(s) or to create a similar GExpert which gets the CLASSNAME instead of the component name. (The former solution could include an additional keyboard-shortcut configuration for the classname, inside the same GExpert). So I looked at the GxOtaGetComponentName function: function GxOtaGetComponentName(const AComponent: IOTAComponent): WideString; var Component: TComponent; begin Assert(Assigned(AComponent)); Result := GxOtaGetComponentPropertyAsString(AComponent, NamePropertyName); if IsEmpty(Result) then begin Component := GxOtaGetNativeComponent(AComponent); if Assigned(Component) then Result := Component.Name; end; end; The parameter NamePropertyName is defined as a constant with the value 'Name'. Since there is no constant NamePropertyClassName, I assume that the class name of a component can be in any case simply retrieved by Component.ClassName and has not necessarily be retrieved by GxOtaGetComponentPropertyAsString. So I would naively propose this function to get the class name: function GxOtaGetComponentClassName(const AComponent: IOTAComponent): WideString; var Component: TComponent; begin Result := ''; Assert(Assigned(AComponent)); Component := GxOtaGetNativeComponent(AComponent); if Assigned(Component) then Result := Component.ClassName; end; What do you think?

Now I have tried it out by replacing the old function GxOtaGetComponentName with the new function GxOtaGetComponentClassName in the unit GX_CopyComponentNames: CurrentComponent := FormEditor.GetSelComponent(i); //ComponentName := GxOtaGetComponentName(CurrentComponent); ComponentName := GxOtaGetComponentClassName(CurrentComponent); It works perfectly. Now it's time to decide how the new functionality Get Component ClassNames should be implemented: 1. Combine the component name and class name in one string, e.g.: ComponentName (ComponentClassname) 2. Provide a second keyboard-shortcut box for the class name inside the existing GExpert, e.g. F5 for the component name and CTRL+F5 for the component class name 3. Create a separate GExpert for the component's class name. Plus: Provide a small configuration dialog where one of the above choices could be configured. Please select your favorite choice.

Now I have done it: Got me a Mac (MacBook Pro 16", 64 GB RAM, 4 TB SSD, 8 GB Graphics) with Parallels Desktop Pro and Windows Home 10 (not the crippled N-version for EU-ropeans). Installed the latest Delphi RIO 10.3.3 and got ... VERY small IDE UI fonts: In the above screenshot, I combined the IDE with the Windows 10 system settings window where you can see that my text size is set to 150%. The screen resolution is set to the monitor-native 3840 x 1600: on this monitor: LG UltraWide (3840 x 1600 pixel) (87 x 36 cm). So the final question: Is there a way to increase the IDE UI font sizes under these conditions?

I have a question about the list of Identifiers in the Uses Clause Manager: A specific identifier named SaveStringToFile is not found in the list of Identifiers although its unit (the unit name is MiTeC_Routines - it's a licensed unit ) is in the Library Path. Could it be because it's enclosed inside these compiler directives in the interface section of the unit? {$IFDEF RAD6PLUS} procedure SaveBytesToStream(ABytes: TBytes; AStream: TStream); procedure SaveBytesToFile(ABytes: TBytes; AFilename: string); procedure SaveStringToFile(AString: string; AFilename: string); overload; procedure SaveStringToFile(AString: ansistring; AFilename: string); overload; {$ENDIF} That's because of other identifiers OUTSIDE these compiler directives from the same unit ARE being found.

I have tried to clear the parser cache, but the identifier SaveStringToFile could still not be found.

Today I downloaded gexperts-code-r3054-trunk , extracted it to C:\COMP\_Addons\GExperts\GExperts Sourcecode\gexperts-code-r3054-trunk and tried to build it by loading: C:\COMP\_Addons\GExperts\GExperts Sourcecode\gexperts-code-r3054-trunk\Projects\DelphiXx103\GExpertsRS103.dproj into the Delphi 10.3.3 IDE. First, it complained about a file not found OUTSIDE (!) its own directory: [Exec Error] EXEC(1): File "C:\COMP\_Addons\GExperts\GExperts_Version.ini" does not exist. (ENoVersionInfo) So I copied it from C:\COMP\_Addons\GExperts\GExperts Sourcecode\gexperts-code-r3054-trunk\Projects\GExperts_version.ini to the required location. Then it complained about another missing file: [dcc32 Error] E1026 File not found: 'GExpertsRS103_version.res' So I RENAMED (!) C:\COMP\_Addons\GExperts\GExperts Sourcecode\gexperts-code-r3054-trunk\Projects\DelphiXx103\GExpertsRS103.res to GExpertsRS103_version.res. Only after these two actions, the GExpertsRS103.dll could be successfully built and is now happily living in the 10.3.3 IDE: Are these bugs inside the GExperts source code?

You're alright with David making you upset? Don't let your feelings get manipulated. Think rationally. The weather is beautiful today.

Thank you for the suggestion.

Is that a MORAL or RELIGIOUS assessment?

I wouldn't call that just an annoyance. It's a BUG.

Thomas, thanks for your efforts! Please fix that STONE-AGE BUG of not supporting paths that include a space character. CommandLine scripts solve this problem by double-quoting paths.

Thanks, I did that: But that did not change absolutely anything. It seems the text in that dialog box has been written by a person who is being paid writing the silliest text in the whole company. It reminds me of Monty Python. (See the Monty Python sketch "The Ministry of Silly Walks" that best depicts the silly nature of British humor).

Thanks, this is the dialog box which belongs to the mentioned setting (in German) From what I understand from this confusing text, it assumes that the DPI value for the primary display has changed after Windows Logon and that this change is the font of my problems. Since that is not the case, it seems that DPI problems for a single application cannot be solved in this way. Typical Microsoft "problem-solving".

I've added a very useful feature to UCM: Showing the full file path of the selected unit in the StatusBar (this works in all tabs): Double-Clicking on the StatusBar copies the full file path displayed on the StatusBar to the clipboard! Here are the sources: GX_UsesExpert.zip Here is the link to the filed request: https://sourceforge.net/p/gexperts/feature-requests/82/

I also succeeded by using the web installer in a VM. But since you are in a VM, the Delphi in the VM cannot know anything about Delphi outside of the VM.

After having installed CodeSite 5 (not the Lite version distributed for free in GetIt) in the Delphi 10.3.3 on my new computer and running the IDE afterwards I got this error message: Can't load package C:\Program Files (x86)\Raize\CS5\Bin\CodeSiteLoggingPkg_Design260.bpl. The module was not found. How can Delphi tell me that it did not find the module when it obviously knows the path? CodeSite worked well on the same Delphi version on the old computer.

Or the type search could also be performed by: type=TLabel

I LOVE misleading messages. It shows how the human mind often cannot preview the consequences of what he is doing. ("What could possibly go wrong?")

Thanks, David! You nudged me in the right direction! But ...\CS5\Deploy\Win32 was not the right directory (in my case), like from your screenshot. Because when I tried to add those BPLs from that directory to the list of installed Design Packages (Install Packages dialog) then Delphi told me: Only after adding C:\COMP\Raize\CS5\Bin to the PATH variable (instead of the above one), I could then eventually install the CodeSite packages: So now everything is working again! I also had a similar problem with another component package where I solved the problem by adding the directory of that Design Package to the PATH variable. But in that case the problem was solved only after restarting Windows. Could it be that the PATH variable is becoming fully active only after a Windows reboot? And BTW, the PATH variable contains itself the PATH variable: Isn't that a SELF-REFERENCING CIRCLE?

I have tried to add ...\Raize\CS5\Bin to the Browsing path list: ...but it did not help.

That is a wise statement. And a funny one.

I tried to build [r3053] in Delphi 10.3.3. Got this error message: [Exec Error] The command "call ..\..\buildtools\prebuild.cmd "\\Mac\Home\Documents\DELPHI\___ADDINS\gexperts-code-r3053-trunk\Projects\DelphiXx103\GExpertsRS103.dproj"&&call ..\..\buildtools\movedll.cmd "\\Mac\Home\Documents\DELPHI\___ADDINS\gexperts-code-r3053-trunk\Binaries\GExpertsRS103.dll"" exited with code 9009. How can this be resolved?

It seems so.

Attila, it is important to understand comments. Maybe a second reading lesson would be better.