dummzeuch

I have disabled all plugins to make sure it's not one of these causing it.

It was Delphi 6. (That's one of the reasons why GExperts dropped support for Delphi 5).

Apparently that problem still exists in Delphi 12.2 😞

In which way were they buggy? I'm only aware of the wrong declaration of NativeInt as Int64 in Delphi 7 to 2007. These compilers were all 32 bit only, so NativeInt should have been Integer. That was fixed in Delphi 2009.

Your event handler must match the signature of the event to which you want to assign it. Many events are of the type TNotifyEvent, so this is the most versatile event signature. But I'm not sure I understand what exactly you want to achieve. Maybe a universal message handler would be a better fit for your purpose? But such a handler can not just be assigned.

That code was probably written for a Delphi version that did either not have a NativeInt type (Delphi 5 or earlier) or possibly declared it incorrectly. The latter was the case for Delphi 6 to 2007.

Yes, it works as intended with most windows by now. And turning it off is not an option anyway.

The problem is not that the settings are not saved. I checked it and they are. The problem is that the settings are loaded after the scaling has been initialized and that initialization saves the font sizes. Then the settings are loaded and the font sizes are set, just to be overwritten again when scaling is applied after that. This is why the problem only occurs in Delphi 11 and 12, but not e.g. in Delphi 10.2, as I stated above.

HighDPI scaling

The remedy is not to use scaling. 😉 (won't help here either, because the code is still called.) Not yet, unfortunately it's rather complex to fix this, especially since this applies to all dialogs that allow changing the font size.

Argl. Maybe it's me who is suffering from amnesia... I know the culprit: It's the bloody scaling again. It overwrites the font sizes read from the registry with the defaults. But the layout should not be affected by this, and in my installation it isn't.

Since this is no dockable window, saving the IDE's desktop is not necessary to save its settings. Just setting them in the configuration dialog should be enough. And it does work for me. Just tested it in Delphi 10.2. You didn't specify which Delphi version you are having this problem with. Am I to assume it's Delphi 12 since that what's listed in your profile?

Delphi shows the first form that is created as the main form. Check your project options, you might have to change the order of forms.

After wasting two days trying to find a solution for this issue, I just filed a bug report with Embarcadero: RSP-44007: Actions / menus display wrong images for plugins Description When a plugin (both, package or dll based) adds actions / menu entries with images using INTAServices.AddMasked and assigns the index of this call to the ImageIndex property of an action, the menu entries associated with these actions do not display the correct image but apparently some random image of the plugin. The same issue also exists in the Customize Toolbars dialog where it also schows the wrong images. I will attach the source code for a plugin based on David Hoyle's example in his book, so I am pretty sure there isn't a mistake. But the first time I noticed this problem was in GExperts. The same code that worked fine in all older Delphi versions now also shows the wrong images. This corresponds to the GExperts bug report #331: Editor Toolbar Configuration buttons Please vote for it. If any of the other plugin developers has got an idea how to work around this issue, I'm open for suggestions.

Which in itself could be a phishing attempt. Just saying.

I have received a few reports about bugs in GExperts in Delphi 10.4.1 that do not occur in Delphi 10.4. Here is a GExperts DLL that was compiled with Delphi 10.4.1. Maybe it will solve some of theses problems. Read on in the blog post.

Hm. my "larger code" is the test program here: https://svn.code.sf.net/p/dzlib/code/dzlib/trunk/tests/AutoCompleteTest Which isn't much more than a form with a few TEdits and calls to the various TEdit_AutoAutoCompleteXxx procedures in the constructor: constructor Tf_AutoCompleteTest.Create(_Owner: TComponent); var sl: TStringList; begin inherited; TEdit_ActivateAutoCompleteDirectories(ed_AutoCompleteDirs); sl := TStringList.Create; try sl.Add('one'); sl.Add('two'); sl.Add('three'); sl.Add('four'); sl.Add('five'); sl.Add('six'); sl.Add('seven'); sl.Add('eight'); sl.Add('nine'); sl.Add('ten'); TEdit_SetAutoCompleteStringList(ed_AutoCompleteStrings, sl); finally FreeAndNil(sl); end; TEdit_ActivateAutoCompleteFiles(ed_AutoCompleteDfmFiles, '*.dfm'); TEdit_ActivateAutoCompleteFiles(ed_AutoCompleteFilesCallback, AutocompleteFilter); // These masks are passed to Masks.MatchesMask, so they allow something more than just '*' and '?' // wildcards, e.g. '[a-z]_*.dpr' would also work, which matches 'a_blablub.dpr'. TEdit_ActivateAutoCompleteFiles(ed_AutoCompleteFilesMasks, ['*.dpr', '*.pas']); TEdit_ActivateAutoCompletePath(ed_AutoCompletePath); end; procedure Tf_AutoCompleteTest.AutocompleteFilter(_Sender: TObject; const _Filename: string; var _Accept: Boolean); var ext: string; begin ext := TFileSystem.ExtractFileExtFull(_Filename); _Accept := SameText(ext, '.pas') or SameText(ext, '.dfm'); end; Could you please post the code you used to test your .Next implementation(s)?

Unfortunately both your proposed changes to the code of .Next still raise the same "System exception (code 0xc0000374) at 0x77026e13" with "77026db3 ntdll.RtlIsZeroMemory + 0x93" at the top of the call stack" as my original code did in Delphi 12. My changed code works in all versions of Delphi from 2007 up. You are right with the problem in Skip though. I should have read the description more carefully.

My dzlib contains several helper functions to add TEdit-autocompletion for directories, files (with a filter) and generic strings from a string list. All of them worked fine for me and were used in several our internal programs. But that changed when trying them with Delphi 11 as @Carlo Barazzetta found out: Using these functions now raised a system exception as soon as the IEnumString.Next method was being called the first time. It turned out that the way I tried to cheat with the memory allocation of WideStrings no longer works. Read on in the blog post.

Fixed the problem in revision #1737. Something must have changed in the way Delphi handles WideStrings between Delphi 10.4 and Delphi 11. The hack of setting a WideStiring variable to NIL no longer cleared it without decrementing the reference counter, but apparently freed that string. Instead the code now allocates new memory and moves the content to that new memory. Or possibly it never actually worked but for some reason didn't raise an exception until Delphi 11. While I was at it, I moved the boiler plate code to a new class TEnumStringsHelper so all descendants now only need to implement two simple methods rather than four.

The code works fine up until Delphi 10.4 and fails from Delphi 11 on. If I remember correctly, the largest change between these versions was by monitor DPI support, but I'm not sure wether that was for applications or the IDE or both.

For the record: The last Delphi version that had a Borland entry under HKLM and HKCU\Software was Delphi 2007 (BDS 5.0). 2009 and 2010 were under CodeGear and everything after that under Embarcadero.

Sorry, I totally missed this post. I guess answering nearly a year later is kind of limited use for you, but anyway: Regarding 2: There is only very limited support for Win64 (and none at all for non windows platforms) Regarding 1: We (I and my coworkers) use dzlib primarily with Delphi 2007 and Delphi 10.2. There is very limited testing for other Delphi versions. Some part of it is used in GExperts so that one gets wider testing, but TEnumStringFiles is not part of that. Edit: I just tried it with Delphi 11 and I can reproduce the problem. It also happens in Delphi 12. It does not happen in Delphi 10.2 and 2007 so I guess something in the RTL changed. No solution yet. Yes, https://sourceforge.net/projects/dzlib/ is the latest version, or rather https://blog.dummzeuch.de/dzlib/ which links there and will be updated should I ever decide to host the code elsewhere.

If I remember correctly there is a project group for each Delphi version. You load that into the IDE, do a build all and then install all the designtime packages. Since every 2nd package is a designtime package, it is a lot of clicks, but you can leave out those which you don't use.

If I remember correctly, the CE does not contain the command line compiler. The GetIt-Installation for JCL/JVCL requires that, so you can't use that. Your best bet is to load the JEDI packages into the IDE and compile them there.