Uwe Raabe

That is much easier said than done. While increasing the font size inside a text editor control is usually no problem, doing that in a dialog may destroy the complete layout of that dialog. Having larger fonts in an TEdit will automatically increase the height of the edit, but not its width. A checkbox will even keep its height when the font size changes. Using a larger font inside inside a TRadioGroup also leads to unreadable text. What you suggest would require the scaling of all controls including scaling the complete form. That is exactly what the system scaling is made for. If you want larger fonts in MMX dialogs - increase your system scale. Short answer: No. There are other areas where my free time is probably better spent.

I have to admit that I learned about hh:nn being the correct format quite late in my career. Nevertheless is it correct and logical. Using hh:mm just opens a can of ambiguity, makes the implementation more complex, error prone and slow. Unfortunately MS is not so consistent and also uses hh:mm. Note, that while TFormatSettings.Invariant uses the hh:nn format, TFormatSettings.Create(Locale:TLocalId) still falls back to hh:mm mimicking the MS style: if Result.ShortTimeFormat = '' then Result.ShortTimeFormat := TimePrefix + HourFormat + ':mm' + TimePostfix; if Result.LongTimeFormat = '' then Result.LongTimeFormat := TimePrefix + HourFormat + ':mm:ss' + TimePostfix; While we probably cannot drop hh:mm for staying compatible with Windows and older versions, using hh:nn where ever possible for unambiguousness is not that a bad idea.

Just tried with 200% scale and now I can see a glitch in the Insertion position drop down, but the text seems quote fine there, too. In your screenshot the font seems a bit too large. The form is designed with Segoe UI 9pt even for older Delphi versions and it does not pick up the IDE font. Perhaps something special in your environment (f.i. Ease of Access -> Display)?

Ideally it works out of the box, but that is rarely the case. First the VCL has a new default font Segoe UI 9pt, which is a bit larger than the previous. As the IDE makes also use of this, controls with ParentFont = true may be larger as expected. While labels usually handles that with their AutoSize property, CheckBoxes are more prone to clipping their text. (Side note: ParentFont = False doesn't work well either in the moment.) Icons are often the main barrier as you should provide different or at least larger sizes. The problem is using virtual ImageLists on the form or frame, where they are scaled properly, instead common image lists in some data module. Well, that's not the actual problem - that is keeping the old way working for the older Delphi versions, wich don't know about TVirtualImageList in the first place. One approach, when few forms are affected, can be stolen studied from the imagelist editor in PngComponents. It is also used in Project Magician and Selective Debugging, but for MMX I implemented a totally different approach, where explaining would go beyond scope here, I will be happy to help if you need some advice.

I have no idea what's different with your system, but it is looking fine over here (Win10 21H1 Resolution 3840x2160 Scale 150% Delphi 11 with HighDPI aktive) :

There is none - except making them support High DPI, of course. Only top level windows can have their own DPI awareness context, so docked windows share it with the IDE. SetThreadDpiAwarenessContext targets the thread and has the effect that all Winapi calls are done with the given DPI awareness context. I didn't inspect the relevant source code, but you can try to hand the previous context to the dialog and let it temporarily switch back during the file being opened in the editor. Perhaps you can find a place to restore the context somewhere inside the dialog earlier, but I cannot point you to the correct one. The moment when the context can be restored depends on which WinApi calls are executed when. For simple forms it seems to be sufficient to wrap the Create, but that may be different for more complex scenarios.

That is for C++, while in Delphi 32 Bit they are Extended. See Declared Constants

My guess is, in 64 bit Double and Extended are the same and constants are Double, but in 32 bit they are different and constants are Extended. The DoubleField matches the Double and Extended type as well as the Extended constant does, so the compiler doesn't know what to select.

At least I didn't make that up by myself: So anything below Sydney is probably running on Windows 7 and there already is a check for this: {$IF CompilerVersion < 34.0 Delphi 10.4 Sydney }

Win 7 probably doesn't provide the API used to detect if the system is running in High DPI (not that Delphi 11 can run with or without High DPI) or not. I didn't expect Win 7 still to be a valid scenario. Seems that needs some more sophisticated approach. For Win 11 I am unable to test, as I cannot run it here in the moment.

Up to now I am not able to reproduce. Unfortunately the error messages are of little help here.

Good hint! Actually it happens when the IDE integration page is called twice without closing the dialog in between. Will be fixed soon.

Can you try to delete the layout file reverting to the original one and try again?. I was not able to reproduce that here. Also the A component named BDS17Box already exists. error is a bit puzzling.

If the form is showed modal you can try to wrap the whole thing: procedure ShowGXConfigurationForm; var previousDpiContext: DPI_AWARENESS_CONTEXT; frm: TfmConfiguration; begin previousDpiContext := SetThreadDpiAwarenessContext(DPI_AWARENESS_CONTEXT_UNAWARE_GDISCALED); try frm := TfmConfiguration.Create(nil); try frm.ShowModal; finally frm.Free; end; finally SetThreadDpiAwarenessContext(previousDpiContext); end; end; I have to say that I didn't test nor use this approach in a DLL, especially not in an IDE plugin. So there might be more intricacies than I am aware of.

I am quite satisfied this time. From the issues in QP created by me there are 17 closed as Fixed in Delphi 11. The oldest is from Feb 2017, but most are from 2020 and 2021. Counting over all Delphi versions in QP there are 53 from 78 issues of mine fixed now. Not that bad.

Yes. I just executed Host Licenses to achieve that. Perhaps the license isn't upgraded on the Emba side yet? I had to wait a few minutes after GA, but that might differ for others. There is also a web link at the bottom of the License Hosting page of ELC where you can get the server license files manually. Beware that it is HTTP and it requires your certificate user name and password, so you might want to change that to HTTPS before. It says Delphi 11.0 Alexandria Architect and C++Builder 11.0 Alexandria Architect . It says RAD Studio 10.2 Tokyo Architect (that was the version I switched to a network license). Well, it says RAD Studio 11 Alexandria, but that seems to be a close match.

Confirmed! 👍

Contact their installation support?

I had Delphi 11 installed on my build server with the beta key. After updating the named network license on the ELC server, exporting the slip file and importing it with the license manager, I could simply remove the beta key and Delphi 11 started without any problems using the ELC server license. (I know I could get away with no license on the build server at all unless I start the IDE itself, but this way it is less tedious)

Yes, I know. My answer was directed to Thomas' post about the missing slider, which affects the code editor font size, and the question about it being from a 3rd party plugin or not. It is not and it is also not missing in my installation.

No, it is standard and I can actually see it in Delphi 11 - directly right to the encoding drop down.

With Delphi 11 release a few minutes ago, MMX Code Explorer is already supporting it: Change log V15.0.44

StrToDate and StrToDateTime fail if ShortDateFormat is dd-MMM-yy StrToDateTime doesn't recognise mmm / mmmm formats - undocumented

Or you place a replacement for StrToDate in a separate unit MyDateUtils or so and use that all over the your projects. At least that is less tedious than replacing all StrToDate calls and having to remember a new function name. I suggest filing a feature request in Quality Portal. (didn't check if some already exists)

Green