PeterPanettone

You can process the DCU files whenever you want, MANUALLY: It says: "This command will list all the DCUs files that you don't have access to .PAS and process it to make it available for search." PS: And it would be easy to make it process only those .DCU files where there is no .PAS file with the same name.

There is absolutely NO logic in searching only for identifiers STARTING with the search term. Searching for identifiers CONTAINING the search term is the sensible way to go. Or you could add an option radio choice "Starts/Contains the search term".

RFindUnit finds madShell.newShortCut - so UCM should also find it. Why it doesn't?

Here are the settings: As you can see, the "Parse all units" option is checked. PS: I have also cleared and rebuilt the UCM cache. Still no results for "newshortcut" yet. (However, a search for "newcolor" got 6 results).

1. The Unit Dependency Analyzer lists both Classes and System.Classes: Isn't there an option to suppress these multiple unit names which differ only by namespace? (The preference should be given to fully qualified namespace). 2. As you can see from the above screenshots, both are indicated as "no source found": This is strange, as the source file is located here and should be found: c:\program files (x86)\embarcadero\studio\18.0\source\rtl\common\System.Classes.pas MMX13 in Delphi 10.1 Berlin

BTW, in the Dependency Analyzer Settings, in the Compiler version dropdown menu there are only Win32 compiler versions listed: Why are there no Win64 compiler versions listed, as my project is for the Win64 platform?

Does anybody know an IDE addin that can create a project-wide uses-clause report, i.e. a report containing all uses-clause unit-names from all units in the project (without doubles)? For example: Unit1 contains this uses clause: uses Winapi.Messages, System.Variants, System.Classes, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, AdvEdit, AdvEdBtn; Unit2 contains this uses clause: uses Vcl.Controls, Vcl.Forms, Vcl.Dialogs, AdvGlowButton, Vcl.ExtCtrls; The report would then contain: Winapi.Messages, System.Variants, System.Classes, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, AdvEdit, AdvEdBtn, Vcl.ExtCtrls, AdvGlowButton;

Thanks to all!

Is there an IDE addin to automatically change for example this: var I: Integer; into this: var I: System.Integer; and this: uses Messages, Variants, Classes, Controls, Forms, Dialogs, StdCtrls; into this: uses Winapi.Messages, System.Variants, System.Classes, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls

Thanks. You mean this one? May I add a suggestion: For USER FEEDBACK, change the color of the unit names in the UCM list to another color after the processing. Would be useful. BTW: Where does UCM get the namespace prefixes? ...and it would be nice if it could do for the WHOLE PROJECT, as an option.

Is there a way to add a system-menu item to all applications? (Not just only to my own application).

On your GitHub web page. I didn't change anything, just compiled your demo.

I have downloaded it and tried the GetMsgHook demo (Delphi 10.3.1, Windows 7 x64): The 32-bit worked well straightaway, without signing the DLL etc. The 64-bit version did not work the first time, so I followed the recommendations from the GitHub page: • uiAccess="true" • Code MUST be digitally signed • Your application MUST reside in a trusted location (e.g.; Program Files) As the 64-bit version still did not work, I tried to trace all methods in HooksMadeEasy.GetMsg.pas with CodeSite. So I saw that the procedures TGetMsgHook.Hookup and TGetMsgHook.Stop worked well, but then the tracing in the TGetMsgHook.GetMsgProc loop seemed to get too much strain on my system and messed it up so I had to reboot the computer. Strangely, after rebooting and recompiling the 64-bit DLL without the GetMsgProc tracing, the 64-bit version suddenly DID WORK: Clicking a system menu item in a 64-bit program showed up in the TestGetMsgHooks.exe feedback list. 1. So why did it work with 64-bit programs only after rebooting? 2. To make it work with BOTH 32-bit programs and 64-bit programs supposedly I would have to start BOTH a 32-bit exe with a 32-bit DLL AND a 64-bit exe with a 64-bit DLL? Or is there a way to activate both the 32-bit hook AND the 64-bit hook with ONE SINGLE exe?

Thank you very much!! I am sorry for my late answer, I was away for a personal issue. PS: How can I show you my gratitude? May I send you a small donation?

... that would be GREAT!

Are there any grown-up people here?

That's what I am doing. But it does not work with 64-bit DLLs. See my attached code example above.

But it works well with 32-bit programs. How can it make to work with BOTH 64-bit programs and 32-bit programs?

The package he created is here: http://www.vclcomponents.com/Delphi/System_Components/Hooks_Made_Easy-info.html

It seems that the author of this code is Fred Schetterer. (Los Angeles?). But his website http://www.fredsterware.com/ does not exist anymore, so I don't know how to reach him. Does anybody know him?

When I use this call instead of the previous call in \fwGetMsgProc\MapFile.pas then there is no more error in the DLL code in the function Hookup in the line GetMsgProcRec^.Hwnd := Hwnd However, I also do not get a callback when clicking on any system menu item in any application.

Unfortunately, when I try to start a debug session for any Win64 project in my Delphi 10.3.1, I get the following error (debugging Win32 projects does work): Why is there an error in a CPP file if I try to start a debug session for a DELPHI project? Then I click any button, then this error message pops up: So, unfortunately, I cannot debug the Win64 projects.

I have found a code example that works perfectly and gets a callback when clicking a system menu item in ANY application! It adds a system-wide hook to WM_SYSCOMMAND messages by using a DLL. (Unfortunately, it works only with 32-bit programs): AddSystemMenuItemToAnyApp2.zip I have tried to make it work with 64-bit applications by compiling the projects (EXE and DLL) as Windows 64-bit platform. I did not succeed. I made these changes in the DLL code: • THandle is different on the 64-bit platform: System.UInt64 • The error seems to be in the DLL code in the function Hookup in the line GetMsgProcRec^.Hwnd := Hwnd: Access violation at address 0000000003585C9F in Modul 'fwGetMsgProc.dll'. Reading from address 0000000000000000. • Also, in the EXE code, in the Button5Click handler I changed: @Hookup := GetProcAddress(hGetMsgProc, Pchar(LongInt(1))); to: @Hookup := GetProcAddress(hGetMsgProc, PAnsichar(LongInt(1))); But, as I said, I did not succeed: There is still the above-mentioned access violation in the DLL code. Could anybody with more experience have a look at the code and successfully compile it to 64-bit? The only code portions you would need to look at are: • The Button5Click handler in the EXE code • The DLL code which is just a few lines

I don't know any official Delphi library which does process injection. Is there any?

I created a test project (see attachment) which can add a system menu item to my own application or to any other application (tested with notepad: get the notepad window handle). However, reacting to the click event of the added system menu item works only when added to the own application. How can I make it sending a message to my application's window? AddSystemMenuItemToAnyApp.zip