Uwe Raabe

This should explain it: if (ParentMenu <> nil) and (ParentMenu.OwnerDraw or (ImageList <> nil)) and (Assigned(FOnAdvancedDrawItem) or Assigned(FOnDrawItem)) then

@Stano No, that's the Parameter Wizard. Attributes can be added with this button: or alternatively with the Explorer or Editor context menu Tools - Insert Attibutes

First there is the Lock Controls feature of the IDE, which prohibits any position or size changes during design for all controls. If we are talking about some specific controls made by yourself and registered in some design time package, you can override CanResize and return False when in design mode. function CanResize(var NewWidth, NewHeight: Integer): Boolean; override; ... function TMyControl.CanResize(var NewWidth, NewHeight: Integer): Boolean; begin if csDesigning in CompontentState then Result := False else Result := inherited CanResize(NewWidth, NewHeight); end;

Did you install EdgeView2 SDK from GetIt?

OK, it is not official, but I will share some internals here. You can change the titles of the Welcome Page items to clickable links with a secret registry setting: Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS\22.0\WelcomePage] "ActivateLinkOnTitle"=dword:00000001

The correct help file can be downloaded from here: https://docs.embarcadero.com/products/rad_studio/index.php Place the chm as topics.chm in the appropriate folder under $(BDS)\help\doc

Well, I see the font size (and thus TFont.Size) as an invariant in regard to the dpi of the media it is displayed. Keeping the font size constant when changing dpi will always neutralize any rounding errors due to consecutive dpi changes. It doesn't matter if that the current and past implementation doesn't follow this approach. It is never too late to do it right. Nevertheless I respect when you disagree with this. BTW, regarding TFontDialog and High DPI: https://quality.embarcadero.com/browse/RSP-34122

While your points may be valid, I actually disagree with some of these statements. As always everyone can have ist own view on these things. Often there is no simple right or wrong. The advantage of my suggested approach is, that it fixes a whole bunch of scaling errors still existent in Delphi 11. If the cost for this is breaking existing code - I can live with that.

I may be wrong, but I think the underlying reason is: Font.Size and Font.PixelsPerInch do not respect per-monitor scaling This has been discussed a lot and font scaling is now re-evaluated. I proposed some changes for the VCL that can even be rolled out as a hotfix (i.e. no interface breaking changes), although not really a perfect solution, which requires TFont.PixelsPerInch moved to published. These changes do work, at least for the test cases we currently have. Unfortunately it cannot be used when compiled with packages. The easiest workaround for the moment is to use ParentFont = True as much as possible. TForm.Font is currently handled quite well and that can be adopted with this setting. Of course one loses some design variance.

Putting bad things onto a non perfect system just makes it worse, not better. I know it can be hard to get things working when the fundaments are fragile, but I found and reported a whole bunch of issues while working on MMX for Delphi 11. It was expected that not all of them make it into the release, but a good portion will probably make it into update 1. They wouldn't if I would have given up halfway.

I have two 32" 3840x2160 monitors both 150% scaled. That gives me the same resolution as my 24" 1920x1080 previous ones on 100% ( 24 / (32/2) = 1.5 ), but with 33% more real estate. Lower scaling doesn't fit my eyesight. For testing I use different monitor and scaling layouts in a VM. I can confirm from my own experience with MMX that supporting High DPI in an IDE plugin can be a bit tedious.

This is the original I uploaded: https://drive.google.com/file/d/1RkPmrRffpr7ra917RRcHMar-vFefEgYp/view?usp=sharing

Indeed, I would never do that to MMX. Actually I would buy it myself if I would have any use for it that pays back. Usually I work for customers help them maintain or extend their existing software. Sometimes there are a couple of developers working on the project, sometimes I am the only one doing that. From all these dozens of customers I had in all these years only one had DevExpress and then only the grid. It doesn't matter what I think about DevExpress when the customer refuses to buy it. If the customer already uses DevExpress - no problem. So, if someone wants to write an MMX clone with the DevExpress Ultimate Layout Solution - go ahead.

Sorry, I cannot see anything blurry in my screenshots. Not sure how I can prove without doing the same as I have done before. The 150% picture is 835x1071 originally, while the 200% is 1078x1306. I admit that there some controls still have small sizing problems due to the scaling, which I cannot explain for now. Actually the scaling is done by IDE/VCL itself. Perhaps some AutoSize goes haywire here. Anyway, it is definitely not blurry here and it is even not when I inspect the picture in my comment. As a reference, this is a screenshot from Delphi 10.4.2 with the same dialog (838x1069) bitmap scaled 150% by Windows (that one is blurry): Perhaps you can post what you see?

You are probably referring to the thumbnail displayed in the comment. Click on it and you should see the real size.

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.