UPDATE: The problem was that I was using Delphi 10.2.2 build 1978. Apparently I have missed an update in December 2017 to build 2004. I have downloaded and installed the new version, and now the patch worked fine.

I hereby apologize for being stupid, because it clearly says in the description:

This patch for RAD Studio 10.2.2 (build 2004 — it won’t work on build 1978) resolves some compatibility issues in the RTL and fixes a problem with Android animations. It is designed to be installed only on top of an existing RAD Studio 10.2.2 Tokyo installation.

(emphasis mine)

I was so sure to be running the latest version that I didn’t even check. Sorry about causing so much fuss.

I’ll leave the rest of the blog post unchanged just in case anybody is googling for some of the key words and to remind me to check first and complain later.

After I reported the problem with the Delphi 10.2.2 February 2018 Patch, Embarcadero first removed the download and has now released a new installer. Unfortunately this new patch might have solved some other problems, but it didn’t solve mine. I did a complete uninstall of Delphi 10.2.2 (I even removed all directories and files that the uninstall left behind) and a new installation from my DVD followed by applying the new patch. I could still not compile GExperts and the simple test program I described in the steps for the bug report did not compile either. (Guess what: Embarcadero apparently never actually tried to reproduce my problem, but the ticket was closed anyway.). I don’t know what exactly they think they fixed, but they didn’t fix the problem I reported which is:

RAD Studio 10.2.2 Tokyo February 2018 Patch breaks “Link with rutime packages”

1. Create a new VCL project
2. Open project options
3. Select Packages -> Runtime Packages
4. Set “Link with runtime packages” to true
5. Close dialog with OK
6. Compile the project
7. -> Error

Today I tried to find out what the problem was and how to fix it. It turned out to be actually quite simple:

They updated the packages rtl.bpl and fmx.bpl together with their corresponding .dcp files. Since the .dcp files contain some versioning information the packages that use these packages (e.g. vcl.bpl which uses rtl.bpl) were no longer compatible with the new packages and the compiler complained about this.

So, the fix for this would be to recompile all the packages depending on rtl.bpl and fmx.bpl, but since I don’t have all the sources required for that, I couldn’t do that (but Embarcadero should).

What I did instead was replacing the .dcp files in libs\win32\debug and libs\win32\release with the .bak files that the Patch created. Afterwards, GExperts compiled again. And since probably the interface of the bpl files didn’t change, I don’t expect any problems. But of course, I can’t guarantee this. So, if you follow my example, you might still run into problems and, No, I won’t fix your computer. 😉

The Unicode issues in GExperts just don’t end. Today I fixed three of them:

procedure bla;
begin
SomeVar := 3245;
// german description with some äöüß to SomeVar
SomeVar := 123;

SomeQuery.FieldByName('GermanWordWithäöüß').AsString := 'some value';
end;


(Yes, I know, this doesn’t compile.)

• Move the cursor to the first occurrence of SomeVar and press Ctrl+Alt+Down. The cursor jumps to the middle of the next Occurrence of SomeVar instead of the start of the identifier.
• Move the cursor to the opening parenthesis after FieldByName and press Ctrl+Alt+Right. The cursor moves to somewhere in AsString rather than the closing parenthesis.
• Move the cursor to the closing parenthesis and press Ctrl+Alt+Left. You get the error that AsString is not a valid delimiter

They were caused by the two byte UTF-8 characters in the respective lines which threw off the column index.

And if that wasn’t enough I also fixed some bugs in the Grep history list which could cause an Access Violation, infinite loop or wrong check marks in the Open dialog.

All these were reported by Konstantin Tkachenko who also included some patches which fixed them. Unfortunately he could only test them in Delphi 2010 so they worked for Delphi 2007+ but not for Delphi 6 and 7. They were valuable nonetheless. Thanks Konstantin!

Also, Achim Kalwa, who already contributed quite a few patches to GExperts, sent me some more this week:

• Remove the ugly “(S+C+x)” suffixes in the Project Options dialog and replace them with a hint.
• Sort the component names by tab order in the Copy Component Names expert.
• Shortcuts for Add/Remove/Default buttons in the Editor Popup menu configuration dialog as well as sorting the list of experts alphabetically.

Flattr have changed their terms an conditions. Since I haven’t received a single cent via Flattr, I really can’t be bothered what exactly they have changed and whether that’s good or bad for me personally. So I have closed that account for good. That leaves only PayPal, if you want to make a donation to GExperts. Sorry, if that’s an inconvenience. And please remember that I’d prefer you to contribute to GExperts in one of the other means described on that page than money.

Jeroen has submitted two enhancements to GExperts:

Thanks!

I am still working on the refactoring for the IDE form enhancements, but progress is slow, so the next release will probably take a while.

I have started to write some documentation on the internal workings of GExperts. For now, it covers only a very small part of the IDE form enhancements that GExperts provides. It is meant mostly for myself to get an overview of that part of the tool which has grown too large to understand at a single glance. But it might also help if somebody wants to contribute to that part.

Donations for GExperts keep coming in. It’s more a trickle than a flood but hey, I’m not in it for the money. And please remember that I prefer other kinds of contributions over money.

I have used that money in turn for donations to

I would have liked to also donate to PuTTY and FileZilla but I found no way to do it.

(Yes, there is a donate link on the FileZilla SourceForge page but it doesn’t work.)

The method of changing the order of the TabSheets in a PageControl in Delphi is not obvious. Apparently there is no drag and drop support (at least not in Delphi 2007). You have to change the PageIndex property. So, if you want to insert a new page, add it and then change its PageIndex to the insert position.

I smell an opportunity for a new GExperts Expert. Any takers?

EDIT: As Moreno Zenaro pointed out in a comment to my Google+ post, there is actually a GUI way of changing the order: Drag the TabSheet in the structure view.

As I stated before I prefer good bug reports on GExperts over money any time. Philip von Melle kept testing and providing feedback even after I thought the issue was already solved.

The issue was that a Macro Template

(%SELECTION)


used on this code

// öäüß

procedure TForm1.FormCreate(Sender: TObject);
begin
ShowMessage('TEST');
end;


while TEST was selected
generated code like this

// öäüß

procedure TForm1.FormCreate(Sender: TObject);
begin
ShowMessage(''); (TEST)
end;


The reason again was improper use of positions and offsets into the editor buffer in conjunction with some Unicode characters above the code. So the insert position was calculated by 4 bytes too high, hence the macro code was inserted 4 characters behind the start of the original selection.

Note to self: Do not use a watch entry like this while debugging GExperts:

GxOtaReadEditorTextToString(GxOtaGetEditReaderForSourceEditor(nil))


While this might seem very convenient it will sooner or later corrupt the current edit buffer or do something even worse, because, as a comment in ToolsApi states:

WARNING!!!
A IOTAEditReader should never be active at the same time as an IOTAEditWriter.

But having it as a disabled entry in the watch window, enable it to inspect the current content of the edit buffer, before disabling it again can be very useful.

GExperts so far comes with a special stand alone executable GExpertsGrep that does nothing else but load the GExperts dll and call the entry point ShowGrep. Having this additional executable isn’t really necessary because Windows already comes with a tool that does exactly that: Load a DLL and call an entry point: rundll32.exe

rundll32 path\to\your.dll,EntryPoint additional parameters go here


In order for a dll to be called in this manner it needs to export an entry point with the following definition:

procedure EntryPoint(_HWnd: HWND; _HInstance: HINST; _CmdLine: PAnsiChar; CmdShow: integer); stdcall;


Note that the calling convention must be stdcall otherwise bad things happen.

Since Windows NT (so for all modern versions of Windows) there are two additional ways to declare the entry point:

procedure EntryPointA(_HWnd: HWND; _HInstance: HINST; _CmdLine: PAnsiChar; CmdShow: integer); stdcall;
procedure EntryPointW(_HWnd: HWND; _HInstance: HINST; _CmdLine: PWideChar; CmdShow: integer); stdcall;


Note that EntryPoint and EntryPointA are still assumed to have a PAnsiChar parameter, while EntryPointW is assumed to have a PWideChar parameter. A Dll only needs to export one of these entry points.

If RunDll32 is called with “EntryPoint”, it will look for “EntryPointW” first, “EntryPointA” second and “EntryPoint” last. Note that you don’t have to specify the “A” or “W” suffix, it is automatically added by RunDll32.

For a change, we even have an advantage when writing the DLL in Delphi rather than in MS Visual C++: Delphi does not do any name mangling, so the entry point will be called exactly what you write in the source code.

So, assuming the GExperts DLL exports the following procedure:

procedure ShowGrepEx(_HWnd: HWND; _HInstance: HINST; _CmdLine: PAnsiChar; CmdShow: integer); stdcall;


RunDll32 could be called like this:

rundll32 path\to\GExperts.dll,ShowGrepEx Some\Directory\here


The DLL would take the _CmdLine parameter, use it as the base directory for a directory search and show you the dialog as above. Pretty cool, eh?

We could even go a step further and write the following to the registry to add an entry to the context menu of each folder in Windows Explorer.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Folder\shell\GExpertsGrep]
"Icon"="path\\to\\GExperts.dll"
"MUIVerb"="GExperts Grep"

[HKEY_CLASSES_ROOT\Folder\shell\GExpertsGrep\Command]
@="\"c:\\windows\\system32\\rundll32.exe\" path\\to\\GExperts.dll,ShowGrepEx %1"


(Note: Don’t just copy that to a .reg file! You need to replace both instances of “path\\to\\GExperts.dll” with the actual absolute path to your GExperts DLL. And don’t forget that the current release does not even export the entry point ShowGrepEx at all.)

And this is what you’d get:

Unfortunately there is a drawback: RunDll32 must be given the correct path and file name of the DLL to load. That’s fine if you only have one GExperts version installed. The current GExpertsGrep stand alone executable searches for the first GExperts DLL in descending order, so it will always load the one for the latest Delphi version it can find. So I am not sure whether I want to drop the stand alone executable in favor of RunDLL32 right now.