dummzeuch

I have got a curious effect with Delphi 12.2 (maybe it has already been there in Delphi 12.1 but I didn't notice it): When starting the IDE and opening a source code file in the editor, the gutter (the panel left of the source code containing line numbers and breakpoints etc.) has some given width. After a few seconds that width gets larger by approximately 16 pixels, moving everything to the right. This happens only the first time after starting the IDE. After that, closing and opening files keeps that new width. This is on a HD monitor with 1920x1200 pixel resolution and no scaling. Has anybody else noticed that effect?

At least one of my bug reports got resolved in Delphi 12 partially : IDE Menu does not display correctly when moving from one main menu item to another https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-516 This no longer happens the same way, but moving from Run to Components using the right arrow key now only highlights the Menu item without showing the menu. Pressing the down arrow key then shows the menu, so I guess I can live with that partial fix. Moving from Edit to Search with the right arrow key works as expected. Unfortunately the two most infuriating bugs since Delphi 11 have still not been fixed: IDE toolbars get scrambled over time https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-515 Switching Desktops does not work properly when using some mixed High DPI und HD monitor setups https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-514

I'm pretty sure installing different versions of CE on the same PC will work. But I have never used CE myself, so this is only an (educated) guess based on what I know about having multiple regular Delphi installations on the same PC. It would be a good idea to have an up to date image backup of your PC before trying it though.

They used to have a home grown QM system and replaced it for a reason.

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.