dummzeuch

There is a now an installer for version 1.3.19 Alpha of GExperts for Delphi 11.

You mean this one? {$IFDEF IDE_IS_HIDPI_AWARE} if MinWidth < 1000 then MinWidth := 1000; if MinHeight < 1000 then MinHeight := 1000; {$ENDIF} I don't even remember why I added it. I probably was totally frustrated with trying to get that dialog working in whatever way with Delphi 11 on high DPI, that I simply pulled some absolute values out of my hat so see whether they work. Surrounding it with if TScreen_GetDpiForForm(Self) > 96 then begin end; Will probably solve this one particular problem.

I bet if we look hard enough, we will find remnants from pretty much any old Windows version in there. I also bet that it still comes with the driver for the obsolete "Microsoft Ballpoint Mouse" and automatically installs it when a GPS is attached via a USB serial adapter. An annoyance which I had to put up with since Windows XP.

Hm, the minimum height for this form is set to 660 pixels. That might be a bit tight depending on the height of your task bar. On top of that there might be the general scaling problems in Delphi 11, but I actually doubt that this is the issue. If you want to, get the sources, change the height of the GX_Configure form to e.g. 600 and compile your own DLL.

I consider multithreading as hard enough to not use it if it isn't necessary. And there are many types of programs where it isn't. In particular, as you said, the lack of proper debugger support makes it hard.

What's your screen resolution and scaling?

The last time I looked, they not only did not supply such a file, but also shipped an ancient version of jedi.inc (with the DUnit sources if I remember correctly). I had the misfortune of including that directory in the search path once and it took me hours to find the cause for the sudden compile errors.

Actually, the $IF compiler directive appeared in Delphi 6.

Great, just what I need. GExperts for Delphi 11 just got pushed further into the future. I'm really despairing with this high DPI stuff. Maybe I should just give up and wait for 11.1. There are more fun things to do with my spare time than trying to somehow work around all those bugs in Delphi 11.

There is probably a central include file that needs updating for Delphi 11. And most likely this will fix all the compile errors.

The GroupView property was one of the compile errors, so apparently wasn't supported back then. No idea, when it was introduced. I currently haven't got the time to investigate further.

Thanks, but unfortunately it does not compile with Delphi 2007 (haven't tried any other versions yet) and after I commented out everything that did not compile, it simply does nothing (Enter opens the currently selected todo rather than filtering.) I'll have a closer look at it later to see whether it is possible to make it work somehow.

It hasn't complained yet. 😉 (16 GBytes of RAM go a long way even with Windows 10, if you don't use VMs) Currently I have got 3 instances of Delphi 2007 and 2 of Delphi 10.2 running (on separate virtual desktops with different projects of course).

That's what the BDSLauncher.exe tool in the Delphi bin directory is for. It's usually registered as default program for *.dpr / *.dproj files. (And it's the first thing I replace because I actually want a separate BDS instance for each project.)

Now would probably a good time to switch to something else. We did that about 15 years ago. Even if they find somebody that solves their problem this time, there is no guarantee that somebody will be able or willing to help out again. I just looked and could not find a link to the source code, it's not on sourceforge either, maybe it's on GitHub.

If I remember correctly there is a "do not show again" checkbox in the dialog.

Yes, definitely. Otherwise strange things will happen sooner later. Usually later, when you have completely forgotten that you did this.

Actually that is a warning message and it can be turned off.

Width and Height are not stored for a form, haven't been for a long time. ClientWidth and ClientHeight are.

Worked for me. (Which is an improvement because installations via Getit used to fail most of the time.)

I use it often to repeat a call to a function where I missed something when stepping trough the first time. Works without a problem for this and saves the time to restart the processing. e.g.: SomeCodeHere; try SomeFunctionCall(SomeParameters); // <== Code raised an exception I need to investigate except on e: Exception do LogException(e); end; SomeMoreCodeHere; // <== so I place a breakpoint here // (after the debugger stopped on the exception) // and then set the execution point back to the function call Of course after that the call stack may be broken, but usually I stop the process anyway to fix the problem.

Looks like you are using GExperts. If yes, turn off the "Goto Previous Modification" and "Goto Next Modification" experts and see whether that solves the problem.

While I agree with you that that's the best use of limited resources, the promise of supporting older versions as part of the subscription still stands, and we paid for it. One could call that a breach of contract.

There is now a GExperts project in the svn repository, that compiles with Delphi 11 (see .\projects\DelphiXx110Alexandria). If you don't know already, there is a page on my blog telling you how to compile your own DLL. It mostly seems to work too, but there are quite a lot of caveats, most related to the new High DPI awareness of the IDE. The simple workaround, if you value GExperts functionality more than the High DPI awareness: Start Delphi with the "Delphi 11 (DPI unaware)" start menu entry. This also fixes quite a few display quirks I have already found in the new Delphi version. If you do that, you should probably also disable all the experts that you don't need, because I haven't tested many of them on Delphi 11 yet at all and they might have undesired side effects even if not actively used. Unfortunately the trick Uwe Raabe blogged about, for using High DPI unaware forms in High DPI aware applications doesn't seem to work. I tried to change the code for opening the GExperts configuration dialog like this: procedure ShowGXConfigurationForm; var previousDpiContext: DPI_AWARENESS_CONTEXT; frm: TfmConfiguration; begin previousDpiContext := SetThreadDpiAwarenessContext(DPI_AWARENESS_CONTEXT_UNAWARE_GDISCALED); try frm := TfmConfiguration.Create(nil); finally SetThreadDpiAwarenessContext(previousDpiContext); end; try frm.ShowModal; finally frm.Free; end; end; But it changed nothing. The Dialog is still displayed too small to comfortably use on a 4K monitor with scaling set to 150. I'll try to get this sorted. Any help will be appreciated.

One or multiple monitors? Which resolution and DPI?