Uwe Raabe

I suspect the field is a string field?

AFAIK, they will provide the API with one of the following updates when the internal interfaces are more mature.

Drop down the Options button (the right most) and uncheck Auto Track.

The requested functionality can be hacked together with a few lines of code. Place this interposer class in the scope of your form. type TDBGrid = class(Vcl.DBGrids.TDBGrid) private procedure WMVScroll(var Message: TWMVScroll); message WM_VSCROLL; end; ... procedure TDBGrid.WMVScroll(var Message: TWMVScroll); begin if Message.ScrollCode = SB_THUMBTRACK then Message.ScrollCode := SB_THUMBPOSITION; inherited; end;

Not more than a FetchAll would do. It is similar to repeatedly pressing PgDn.

What about filing a feature request?

TCustomGrid and its descendants don't support that.

My layout is a root folder that contains all external libraries as sub repos in a separate sub folder named lib, while the project is located in the source sub folder. This keeps the lib stuff out of the "search in files in project dir".

I know, but I also know how these things are usually going.

Right when this thread started I thought: This may quickly turn into a Git client contest.

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.