In my last post I wrote about the export and import feature for custom Tools menu entries that GExperts adds to the Delphi IDE. I also mentioned that I was thinking about adding a custom clipboard format for copying and pasting these entries between multiple Delphi instances / versions.
OK, I did that. GExperts now also adds a popup menu to the Tool Properties dialog with two entries:

• Copy entry to clipboard
• Paste entry from clipboard

These entries use a custom clipboard format registered with Windows as "Delphi.ToolsEntry". It’s a binary format with the following structure:

• Size: UInt32 -> the size of the structure
• Title: array of WideChar, zero terminated
• Path: array of WideChar, zero terminated
• WorkingDir: array of WideChar, zero terminated
• Params: array of WideChar, zero terminated

With this popup menu it is now possible to copy and paste Tools menu entries between multiple instances of the Delphi IDE. This works also between different Delphi versions, so you can copy the entries from Delphi 10.3 to Delphi 6 and vice versa.

There is no new GExperts release for now (I am waiting for the next Delphi point release which should be just around the corner. I’m just guessing, I have no internal knowledge about the release schedule.). In the meantime, if you’d like to get this feature, you will have to compile your own GExperts DLL.

If you would like to comment on this, go to this post in the international Delphi Praxis forum.

The Delphi IDE has the quite useful option to add custom entries to the Tools menu. These entries call external programs with some “Macros” that reference the current IDE status, e.g. the currently active project or source file and some of their properties like the output directory or the current editor column and row.

GExperts already enhances the Tools Properties dialog by adding auto completion for the file name and the working directory (for Delphi 6 and 7 it also adds support for Drag and Drop, but that doesn’t work for later versions).

It has always irked me that there was no easy way to port these custom tools entries from one Delphi version or installation to another. I always had to copy and paste four fields to achieve that.

GExperts now adds two new buttons to export and import the current entry:

These buttons write / read Delphi Tool Menu Entry files (*.dtme), which are in INI file format an look like this:

[Delphi Tool Menu Entry]
Title=Explore &Source Directory
Path=explorer.exe
WorkingDir=
Params=/e,/select, \$EDNAME


So, to move an entry from one IDE version to another, export it from the first one, add a new entry to the second one and import the exported file.

I’m thinking about adding a special clipboard entry format for this so creating a file to copy these entries will no longer be necessary, but that’s for some future time (which may be very near but maybe not).
Edit: Done, see here.

I am also currently working on a small side project called Delphi Tools Manager which will supply that functionality outside the IDE, but it’s not quite ready for prime time yet. I actually already made a release available but had to withdraw it because I found that there are apparently two different ways the IDE stores these entries in the registry.

There is no new GExperts release for now (I am waiting for the next Delphi point release which should be just around the corner. I’m just guessing, I have no internal knowledge about the release schedule.). In the meantime, if you’d like to get this feature, you will have to compile your own GExperts DLL. But that’s far from being rocket science.

If you would like to comment on this, go to this post in the international Delphi Praxis forum.

Shameless self promotion:

On StackOverflow somebody asked the question in the title and I answered it. And as you might have guessed, I am mighty proud of having had that idea.

It might be interesting to know that this is how GExperts fixes some of the IDE bugs and enhances some forms: It creates a TComponent descendant which hooks some events of the form to implement the fixes or enhancements. And since it is added to the form, it automatically gests freed in the form’s destructor.

If you would like to comment on this, go to this post in the international Delphi Praxis forum.

I had to look them up myself, so it took a while but here they are, the changes, bugfixes and improvements between the GExperts 1.3.12 (released 2018-12-22) and 1.3.13 (released yesterday, 2019-03-30):

• Bugfix (#105): Set Tab Order expert no longer worked with Delphi 6, 7 and 2005 (Remember what I wrote about testing these versions?)
• Improvements to the Uses Clause Manager:
• New configuration setting “GExperts caching directory”, used to store the cached identifiers per unit
• Additional configuration options for the expert: Caching can now be disabled and the cache can be cleared. (Bug report #104)
• It is now possible to use the project’s map file rather than the dpr for getting a list of used units. This includes the VCL/RTL and possibly any 3rd party units and makes the Project tab much more useful.
• Bugfix (#110): Entries in the VCL/RTL list were clipped / overlapped.
• Bugfix (#109): When loading a form’s position only, Width and Height no longer change every time.
• Added additional Delphi 10.2 and 10.3 warnings to the Insert Warn Directive editor expert
• Bugfix: The number of entries for the Favourite Files expert in the registry doubled every time the list was saved.
• Improvements to the Grep expert:
• Hint about separating multiple directories with semicolon.
• It can now use the project’s map file rather than the dpr for getting the list of used units. This includes all units compiled in the project not just those explicitly added to it. There is a configuration option for enabling that.
• Ensure that the RTL and all existing subsystem Paths (VLC, FMX, CLX) are in the drop down menu.
• Searching DFM files can now handle strings split into multiple lines and containing special characters stored as #<number>. (Note: This is not quite finished. The display in the Results window is broken.) (Bug report #112)
• Custom beep as a WAV file for the Proof Reader expert (Suggested by Philip Rayment, Patch by Achim Kalwa, Bug report #111).
• Bugfix (#113): Added another check for duplicate GExperts DLLs being loaded into the same IDE to prevent error message “PrivateGXMenuActionManager is not nil upon creation”
• Project Dependency expert:
• Dramatically improved performance for the indirect dependencies tab. The strings and string lists are no longer stored in and read from the UI. Also string lists are now sorted so look ups are much faster.
• Units in the project (root node of the tree view are now also listed)
• New configuration option to search for units in the library path and also in the browsing path.
• Bugfix (#114): Disabled editor experts still blocked the associated keyboard shortcut and could be called with this shortcut.
• Bugfix (#117): Editor experts could be executed even if not the code editor but the form editor was active.

As you can see above, I am looking into bugs reported on Sourceforge and also feature suggestions posted there. That is my preferred way of users to report bugs and request features because it is easy for me to manage them in one place. The other channels (email via the GExperts “Send a Bug Report / Suggestion” button and the GExperts subforum in the international Delphi Praxis forum) work too, but they are much less convenient for me and some reports / requests may get lost. Also, please remember that I am working on this project in my spare time, so any additional work, e.g. creating bug reports on Sourceforge from emails I receive, takes time in which I am not working on the actual software. It’s also boring work which might discourage me from doing it and if it is getting out of hand might even make me stop working on GExperts at all.

Let me close this post by thanking all those people who have worked on GExperts before me and on whose work I have been building over the years (and whose work I have also been using as a GExperts user for more than two decades as a professional software developer). And also those who continue to contribute their work and some money to this project.

Just in time before April fools day 2019 there is the new GExperts release (it’s still 2019-03-30 so you are safe 😉 ).

Please be aware that I mostly work with Delphi 2007, so this version can be regarded as tested quite well, followed by Delphi XE2. The others are only known to compile and new features are usually tested superficially with all versions. This is particularly true for Delphi 6/7 and 2005/2006.

If you want to help by testing new versions before I release them, please contact me e.g. via Delphi Praxis (link on the side bar) or via the Send Message button on my Sourceforge profile. You may also consider contributing to GExperts. You are supposedly a Delphi developer yourself and it’s not rocket science after all.

Head over to the Experimental GExperts page to download the latest release.

I will blog about the new features later. I have to look them up myself. 😉

Discussion about this post in the international Delphi Praxis forum.

The GExperts Grep Search expert has various options to tell it which files to search:

• The current file
• All files in project
• All files in project group
• A directory list (separated by semicolon)

That sounds like an exhaustive list, but it isn’t. Both, project and project group, were only searching files explicitly listed in the project(s). Files that were linked into the project using the search path, were not searched.

Until now, that is: There is now an option to use the MAP file instead of the DPR file for project search.

The MAP file is created by the linker and contains a list of all source files linked into the program. By default, that file is not created though, you must explicitly enable it on the Linker page of the project options.

The least detailed setting “Segments” is sufficient for the new Grep functionality. If there is no MAP file, it falls back to the original method of searching files listed in the DPR file.

Beware that this will also search units located in the RTL / VCL and FMX source directories. This might not be what you want. I plan to add some more flexibility in the future.

There is no release yet and it might take a while until I feel like doing one, but you can always compile your own GExperts DLL. Make sure you delete the existing directory AppData\roaming\GExperts\DelphiXXX\UsesExpertCache when you replace the DLL with the new one.

Discussion about this post at https://en.delphipraxis.net/topic/793-gexperts-grep-can-use-the-map-file/

If you get the error “PrivateGXMenuActionManager is not nil upon creation” when starting your IDE, check the entries under

HKCU\Software\Embarcadero\BDS\<version>\Expert

There are most likely two entries for GExperts. Remove one and the error should go away.

These entries come from

1. The installer (GExperts=”path\to\dll”), because it always uses GExperts as the name for the entry.
2. The Expert Manager (GExpertsXxx=”path\to\dll”), because it uses the name of the dll file for the entry.

Yes, this is a bug. And it has been fixed on 2019-03-02.

Discussion about this post here: https://en.delphipraxis.net/topic/785-gexperts-error-privategxmenuactionmanager-is-not-nil-upon-creation/

I recently had a problem with access violations when calling methods of interfaces. The reason turned out to be duplicate GUIDs in the interface declarations. This caused AVs because the wrong methods were called and the parameters passed to them were not of the right type and numbers. Duplicate GUIDs are usually caused by copying existing interfaces and changing them, without also generating a GUID for the copy. (Btw: The Hotkey for generating a new GUID in the Delphi IDE is Ctrl+Shift+G.)

So I looked for a way to find all interfaces and their GUIDs in my program. There is a uInterfaces.Duplicates unit on GitHub which claims to retrieve this list. Unfortunately I needed this for a Delphi 2007 program and Delphi 2007 does not come with a System.RTTI unit, so this was not an option (and therefore I don’t know whether this unit would have worked).

StackOverflow didn’t help much either, apart from David Heffernan’s suggestion to parse the source code.

So this is what I did. I used GExperts Grep to search for GUIDs, or more eaxct: For the pattern that is used to add a GUID to an interface declaration in Delphi.

It always looks like this:

type
ISomeInterface = interface ['{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}'];


Where X is a hexadecimal digit in upper case.

The Regular Expression for this is:

$'\{[0-9A-F]{8}-[0-9A-F]{4}-[0-9A-F]{4}-[0-9A-F]{4}-[0-9A-F]{12}\}'$

The literals [ ] and { } must be escaped with a backslash because they have special meaning in a RegEx. [0-9A-F] means one of ‘0’..’9′ or ‘A’..’F’ which is an upper case hexadecimal digit. {4} means four of those {8} means eight and of course {12} means twelve.

You have to turn off the option “Whole Word” and turn on “Regular Expression”. Of course this needs to search at least all files in the project.

Why do I say “at least”? Because actually it needs to search all files linked into the project, including any packages if such are used. “All files in project” only searches files listed in the DPR file, so it’s potentially missing quite a lot.

Which, again, reminds me that I wanted to extend Grep Search to search all files in the MAP file. Code for getting that list is already in place and being used e.g. in the Open File Expert. I “just” need to put the pieces together.

I’m thinking about making yet another Expert out of this, that not only lists all GUIDs but shows a list of Interface names and their associated GUIDs and of course checks for duplicates.

I just fixed two (newly reported) bugs in GExperts:

1. The Set Tab Order dialog no longer worked in Delphi 6, 7 and 2005. This was due to me adding AlignWithMargins (and the associated Margins property) to the dfm file. This property apparently was introduced in Delphi 2006. Again, this underlines what I mentioned several times: I do not use Delphi < 2007 for anything but testing and fixing bugs in GExperts. That’s why glitches like this tend to slip by unnoticed. That’s why I would like people to volunteer for testing the various versions. But apparently nobody can be bothered. Fine by me, but you will have to live with the consequences. I don’t have a QA department.
2. The extensions to the Uses Clause Manager caused several thousand (small) files to be created in the GExperts configuration directory. This directory is located under AppData\roaming\GExperts which means it will be copied when roaming profiles are enabled in a Windows domain. I didn’t know that anybody still uses roaming profiles since they are usually not worth the trouble, but apparently they are still being used. So I now moved that cache to AppData\local and also added a config option to disable caching altogether.

There are now 14 open bug reports on SourceForge. But if you encounter more, please do report them there!

There is no release yet and it might take a while until I feel like doing one, but you can always compile your own GExperts DLL. Make sure you delete the existing directory AppData\roaming\GExperts\DelphiXXX\UsesExpertCache when you replace the DLL with the new one.

btw: Did you notice that I have added menus to my blog?

It’s time for a gift to all Delphi developers, a new Release of GExperts. Happy Holidays! (But do spend some time with your family rather than testing GExperts. 😉 )

I blogged about the new features already. There were also several bug fixes.

Please be aware that I mostly work with Delphi 2007, so this version can be regarded as tested quite well, followed by Delphi XE2. The others are only known to compile and new features are usually tested superficially with all versions. This is particularly true for Delphi 6/7 and 2005/2006.

Head over to the Experimental GExperts page to download the latest release.

Discussion about this post in the international Delphi Praxis forum.