[DevExpress Support Team: CLONED FROM T1073008: Multiple HighDPI scaling issues with skinned application]
Problem #1 has still not been resolved; Ribbon buttons does not scale correctly.
Isn't it about time this got fixed?
We have closed this ticket because another page addresses its subject:
Ribbon button captions are incorrectly scaled if the form's ParentFont is set to TrueRibbon button captions are incorrectly scaled
created 5 months ago
(modified 5 months ago)
Answers approved by DevExpress Support
created 4 months ago
(modified 4 months ago)
Hello Anders,
Thank you for your feedback. We understand your position.
The key point is that IDEs prior to RAD Studio 12 Athens may not handle ParentFont correctly for all cases, so potential improvements may not bring any meaningful benefit since the issue will still take place with standard components.
Regarding the test case with standard VCL controls, I tested it with RAD Studio Alexandria 11.3 and 150% (main) and 100% (secondary) monitors.
Regarding RAD Studio Athens, could you please test the following source code modification? You need to replace the TdxCustomRibbonForm.ScaleForPPI procedure implementation (dxRibbonForm.pas) with the following code:
Delphiprocedure TdxCustomRibbonForm.ScaleForPPI(ATargetDPI: Integer; AWindowRect: PRect = nil);
begin
if ParentFont or not (csLoading in ComponentState) then
inherited;
end;
Comments
(2)
AM
4 months ago
The key point is that IDEs prior to RAD Studio 12 Athens may not handle ParentFont correctly for all cases, so potential improvements may not bring any meaningful benefit since the issue will still take place with standard components.
That's true - but luckily we're not using standard controls; We're using DevExpress controls :-)
Regarding RAD Studio Athens, could you please test the following source code modification?
I can confirm that your modification solves the problem.
AP
4 months ago
Thank you for the update. We plan to add this modification to our source code: Ribbon button captions are incorrectly scaled if the form's ParentFont is set to True.
Hello Anders,
Thank you for bringing this issue to our attention. I re-tested the project from the original ticket and found that the issue takes place only if the form's
ParentFontproperty is enabled:Could you please clarify why it is necessary to enable this property in your project?
We have
ParentFont=Trueon all forms because we need them to useApplication.DefaultFont.This, AFAIK, is the only reason to use
ParentFonton a form.It should be noted that for me the problem only occurs when the primary monitor (i.e. #0) is scaled and the main form is initially shown on that monitor. If it is instead shown on another monitor, then the
WM_DPICHANGEDmessage, when the form is moved before it is shown, will take care of getting things scaled correctly.FWIW, a possible work around is to override the protected Loaded method on the main form with the following implementation:
procedure TFormMain.Loaded; begin inherited; if (ParentFont) and (Monitor.PixelsPerInch <> PixelsPerInch) then ScaleForPPI(Monitor.PixelsPerInch); end;…but it's not perfect since it doesn't give the VCL a chance to also handle the rescale. For example, the form's Font.Height isn't scaled by the above work around.
I would have preferred to simply do a
Perform(WM_DPICHANGED, 0, 0)from the Loaded method but your logic intercepts and eat that so it's never handled anywhere.Hello Anders,
Thank you for the clarification.
Could you please share more details on how you use the default font so we can consider them when examining a possible fix? Did you add the capability to assign the font globally to your application?
Some applications does that and some do not.
Regardless, the main reason to have ParentFont=True on all forms is to avoid forms using a wrong font if/when the system default font changes. For example, Delphi used to have Tahoma as the default font and before that Arial and MS Sans Serif.
Hello Anders,
Thank you for the clarification.
I discussed this use case, and we decided to keep the current behavior as it is due to the following:
As a workaround, you can try assigning required font settings (e.g., font names) manually.
That wans't really the response I had expected.
I know for a fact that ParentFont=True has been in wide use as can be seen by the number of people that have reported issues with it against the VCL's HighDPI support.
I also fail to see how an example of a bug in the VCL (your attached project) has any relevance to the issue I reported. The VCL still has numerous problems with HighDPI (ParentFont=True being one of them) but I really don't expect that to mean that DevExpress should have the same problems. I expect you to solve problems even when Embarcadero fails to.
I understand that any change you make can have potential side effects but if you look at my example workaround you can see that:
ParentFont=True, so it will not affect other cases.ParentFont=True(as I have shown), so any breakage caused by a workaround isn't really relevant; You wouldn't be breaking something that wasn't already broken.