DPI awareness with different monitor DPIs #677
Comments
|
Which version of Delphi and VirtualTreeView are you using? |
|
Sorry I thought last night i should have added this: Windows 10 pro, Delphi 10.1 Berlin (no service packs applied yet), and Virtual Treeview 6.4.1
I’ve just started adding the high DPI support to my application and its a bit of a battle especially trying to support monitors with 2 different DPIs, eg depending on which monitor is set to be my primary one, the window decorations and system dialogs, file open dialogs etc seem not to scale- they run at the DPI of the primary monitor. Everything inside my window's client areas seems happy (mostly) aside from the TVirtualstringviews- which are fine also so long as i don’t move the windows between monitors.
Thanks,
Chris
… On 15/12/2016, at 3:10 AM, Joachim Marder ***@***.***> wrote:
Which version of Delphi and VirtualTreeView are you using?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#677 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AXa962iUXodcHNKdn6X12U_Em9XpydaWks5rH_jtgaJpZM4LMgPR>.
|
joachimmarder
pushed a commit
that referenced
this issue
Dec 14, 2016
…wn the DefaultNodeHeight in TBaseVirtualTree.AutoScale(), to which the paramter isDpiChnage has been added.
|
So far, However, I cannot test this right now because I have connected only one monitor to my PC. Could you please set a breakpoint in |
|
OK Joachim, can i test it for you?
PS just did a test the other way, primary monitor 96 DPI, started application there, dragged to 192DPI screen on notebook and they didn’t scale up either ( I am using theming as well if this is relevant, win10 in this example). Its seems to work (scaling up at least) when the primary monitor is the high-DPI one, and in this scenario (this morning at least!) on some but not all of my virtual treeviews when the primary is low dpi. May have to check the form design ppis as i have edited a few on the high DPI screen…urrrrgh.
I probably need to sort out better what’s happening in my current setup before i can test it reliably for you…
Chris
… On 15/12/2016, at 8:26 AM, Joachim Marder ***@***.***> wrote:
So far, TBaseVirtualTree.AutoScale() only scaled up the property DefaultNodeHeight if the text would not fit into a line. I just added some code that also scales DefaultNodeHeight down if the form's dpi chnages.
However, I cannot test this right now because I have connected only one monitor to my PC.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#677 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AXa962EQ3MJsZDpmg6h6Qv0tQMG-R-Wmks5rIELrgaJpZM4LMgPR>.
|
|
PS, no all my dam files still have pixelsperinch set to 96. Weird...
… On 15/12/2016, at 8:26 AM, Joachim Marder ***@***.***> wrote:
So far, TBaseVirtualTree.AutoScale() only scaled up the property DefaultNodeHeight if the text would not fit into a line. I just added some code that also scales DefaultNodeHeight down if the form's dpi chnages.
However, I cannot test this right now because I have connected only one monitor to my PC.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#677 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AXa962EQ3MJsZDpmg6h6Qv0tQMG-R-Wmks5rIELrgaJpZM4LMgPR>.
|
Sure. Use the GitHub master branch to test, as it already contains one fix compared to V6.4.1. Set a breakpoint on |
|
Thx will have a look tomorrow.
…On Thu, 15 Dec 2016, 20:40 Joachim Marder, ***@***.***> wrote:
OK Joachim, can i test it for you?
Sure. Use the GitHub master branch to test, as it already contains one fix
compared to V6.4.1. Set a breakpoint on TBaseVirtualTree.ChangeScale()
and see what code is executed and why.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#677 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AXa967pktSRqNPsAkoBRQMUp99XnLiSFks5rIO7tgaJpZM4LMgPR>
.
|
Any news on how the master branch worked for you? |
|
We should add a new event |
|
Sorry Joachim was trying to get a release out. Will have a look today.
…On Thu, 22 Dec 2016, 01:33 Joachim Marder, ***@***.***> wrote:
We should add a new event OnAutoScaled, that way one can easily adjust
values that do not fit specific needs.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#677 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AXa96zIqB9PCmnWqD6SRvXvYg7lrGBHeks5rKRyPgaJpZM4LMgPR>
.
|
Any news how the GitHub master works for you? |
|
So sorry Joachim I have been off work for Christmas and summer (here in NZ)
holidays. I am back at work next Monday with my two screen setup and will
try to test then, it got lost in the year end wrap up.
There are other issues unrelated to your treeview I've noticed fyi with the
different dpi screens;. When doing aware the Delphi app always shows system
prompts and dialogs scaled for the DPI of the primary monitor... So I was
largely content in seeing vtv just scale nicely on the single high DPI
screen which it does. But I will test moving between screens.
Chris
…On Mon, 2 Jan 2017, 22:45 Joachim Marder, ***@***.***> wrote:
Will have a look today.
Any news how the GitHub master works for you?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#677 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AXa96zJWrIKFjFSgDBqwluzqWud7H47Gks5rOMdDgaJpZM4LMgPR>
.
|
|
Not quite…
Main screen 96 dpi external monitor.
Secondary screen is 192dpi macbook pro screen (running windows within parallels desktop with retina display set to “best for external displays”)
…--- Monitors info ---
Primary Monitor 0 ppi: 96 left: 0 top: 0 width: 3440 height: 1440 (External)
Monitor 1 ppi: 192 left: -2880 top: 0 width: 2880 height: 1800 (macbook)
App starts on main screen, all looks OK:
Moving it to higher DPI secondary:
Node text scales correctly, but header text does not. (Column widths don’t scale however, and perhaps should also?)
There are 3 virtual treeviews on this form, left two (vstSystems, vstMaterials) don’t seem to adjust their node height correctly, whilst right one (vstCutting) does, though only after a second click anywhere on the form, i.e. initially after dragging it across its rows are squashed, like the others, but after clicking anywhere or dragging the window position slightly it snaps to correct row spacing…odd…) Nowhere it the pas code can I find any reference to me changing or setting the node height so i am confused as to this behaviour.
(I’ve attached the dfm and pas file for this form in case they are useful. All have autoChangeScale set to True)
However on dragging the form back to the 96 dpi main window vstCuttings seems to keep its new expanded nodeheight resulting in bigger than desired line spacing:
I did create a test application with two basic virtual stringTrees as a test case and it performs more or less the same; headers do not scale, the node font does, but the node height does not (rows are squashed)
I’M RESENDING THIS VIA MY WORK MACHINE AS COPY AND PASTE BETWEEN THE WINVM AND HOST SEEMS BROKEN….
chris
On 2/01/2017, at 10:45 PM, Joachim Marder ***@***.***> wrote:
Will have a look today.
Any news how the GitHub master works for you?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#677 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AXa96zJWrIKFjFSgDBqwluzqWud7H47Gks5rOMdDgaJpZM4LMgPR>.
|
|
Update below with basic test application, project files attached. (this email [email protected]<mailto:[email protected]> is a better contact for me)
Primary monitor 96 dpi:
[cid:[email protected]]
Drag to secondary 192 dpi:
(node font scales correctly, node height and header font and height do not. I’ve scaled this by 50% so it looks “the same size” as what I see before my eyes:)
(column width doesn’t scale either, as before I didn’t expect it to but it probably should…)
[cid:[email protected]]
Thanks,
Chris
Chris Were
Software Engineer
[Kinetic ONLY small]
Kinetic Engineering Design Ltd
PO Box 302-608 North Harbour
Auckland 0751
NEW ZEALAND
Tel +64 9 968 8368
DDI +64 9 920 9743
Fax +64 9 968 8365
From: Christopher Were [mailto:[email protected]]
Sent: Monday, 9 January 2017 12:13 PM
To: Virtual-TreeView/Virtual-TreeView <[email protected]>
Cc: Chris Were <[email protected]>
Subject: Re: [Virtual-TreeView/Virtual-TreeView] DPI awareness with different monitor DPIs (#677)
Not quite…
Main screen 96 dpi external monitor.
Secondary screen is 192dpi macbook pro screen (running windows within parallels desktop with retina display set to “best for external displays”)
…--- Monitors info ---
Primary Monitor 0 ppi: 96 left: 0 top: 0 width: 3440 height: 1440 (External)
Monitor 1 ppi: 192 left: -2880 top: 0 width: 2880 height: 1800 (macbook)
App starts on main screen, all looks OK:
[cid:[email protected]]
Moving it to higher DPI secondary:
Node text scales correctly, but header text does not. (Column widths don’t scale however, and perhaps should also?)
There are 3 virtual treeviews on this form, left two (vstSystems, vstMaterials) don’t seem to adjust their node height correctly, whilst right one (vstCutting) does, though only after a second click anywhere on the form, i.e. initially after dragging it across its rows are squashed, like the others, but after clicking anywhere or dragging the window position slightly it snaps to correct row spacing…odd…) Nowhere it the pas code can I find any reference to me changing or setting the node height so i am confused as to this behaviour.
(I’ve attached the dfm and pas file for this form in case they are useful. All have autoChangeScale set to True)
[cid:[email protected]]
However on dragging the form back to the 96 dpi main window vstCuttings seems to keep its new expanded nodeheight resulting in bigger than desired line spacing:
[cid:[email protected]]
I did create a test application with two basic virtual stringTrees as a test case and it performs more or less the same; headers do not scale, the node font does, but the node height does not (rows are squashed)
I’M RESENDING THIS VIA MY WORK MACHINE AS COPY AND PASTE BETWEEN THE WINVM AND HOST SEEMS BROKEN….
chris
On 2/01/2017, at 10:45 PM, Joachim Marder <[email protected]<mailto:[email protected]>> wrote:
Will have a look today.
Any news how the GitHub master works for you?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#677 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AXa96zJWrIKFjFSgDBqwluzqWud7H47Gks5rOMdDgaJpZM4LMgPR>.
|
|
I’ve been stepping through the code and have something of a handle on what’s going on:
As the form moves between different dpi screens autoScale gets called twice:
· First time, isDPIChanged is true, but the font has not yet been scaled/changed, so no change to the dpi.
· Second time through it is bigger and gets set, but only on the “defaultNodeHeight”, no change to the existing nodes.
I’m working on changes to propagate the height change through the existing nodes (and also column widths). I have this working reliably but it will probably cause issues when we save/load the column widths unless we save the column widths at a known dpi, ie the treeview probably needs to remember its current DPI so it can save the column widths as muldiv(width, 96, fCurrentDPI)… something like that anyway.
I’ll look at the header scaling also.
I’ll send through the changes when done for you to review?
Chris
From: Christopher Were [mailto:[email protected]]
Sent: Monday, 9 January 2017 12:13 PM
To: Virtual-TreeView/Virtual-TreeView <[email protected]>
Cc: Chris Were <[email protected]>
Subject: Re: [Virtual-TreeView/Virtual-TreeView] DPI awareness with different monitor DPIs (#677)
Not quite…
Main screen 96 dpi external monitor.
Secondary screen is 192dpi macbook pro screen (running windows within parallels desktop with retina display set to “best for external displays”)
…--- Monitors info ---
Primary Monitor 0 ppi: 96 left: 0 top: 0 width: 3440 height: 1440 (External)
Monitor 1 ppi: 192 left: -2880 top: 0 width: 2880 height: 1800 (macbook)
App starts on main screen, all looks OK:
[cid:[email protected]]
Moving it to higher DPI secondary:
Node text scales correctly, but header text does not. (Column widths don’t scale however, and perhaps should also?)
There are 3 virtual treeviews on this form, left two (vstSystems, vstMaterials) don’t seem to adjust their node height correctly, whilst right one (vstCutting) does, though only after a second click anywhere on the form, i.e. initially after dragging it across its rows are squashed, like the others, but after clicking anywhere or dragging the window position slightly it snaps to correct row spacing…odd…) Nowhere it the pas code can I find any reference to me changing or setting the node height so i am confused as to this behaviour.
(I’ve attached the dfm and pas file for this form in case they are useful. All have autoChangeScale set to True)
[cid:[email protected]]
However on dragging the form back to the 96 dpi main window vstCuttings seems to keep its new expanded nodeheight resulting in bigger than desired line spacing:
[cid:[email protected]]
I did create a test application with two basic virtual stringTrees as a test case and it performs more or less the same; headers do not scale, the node font does, but the node height does not (rows are squashed)
I’M RESENDING THIS VIA MY WORK MACHINE AS COPY AND PASTE BETWEEN THE WINVM AND HOST SEEMS BROKEN….
chris
On 2/01/2017, at 10:45 PM, Joachim Marder <[email protected]<mailto:[email protected]>> wrote:
Will have a look today.
Any news how the GitHub master works for you?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#677 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AXa96zJWrIKFjFSgDBqwluzqWud7H47Gks5rOMdDgaJpZM4LMgPR>.
|
|
Why headers weren’t resizing:
procedure TBaseVirtualTree.ChangeScale(M, D: Integer{$if CompilerVersion >= 31}; isDpiChange: Boolean{$ifend});
begin
if (toAutoChangeScale in FOptions.FAutoOptions) then
begin
fCurrentDPI := M;
if (M <> D) then
begin
//CJW always do this
FHeader.ChangeScale(M, D);
Indent := MulDiv(Indent, M, D);
(* ??? CJW: sfHeight didn't seem to ever be inScalingFlags so header was never scaled
if sfHeight in ScalingFlags then begin
FHeader.ChangeScale(M, D);
SetDefaultNodeHeight(MulDiv(FDefaultNodeHeight, M, D));
end;
if sfHeight in ScalingFlags then
Indent := MulDiv(Indent, M, D);
*)
end;// if M<>D
AutoScale(M , D);
end;//if toAutoChangeScale
inherited ChangeScale(M, D{$if CompilerVersion >= 31}, isDpiChange{$ifend});
end;
…
(I’m storing the “new” PPI (currentDPI as a readonly public property…) so that it can be used to scale column sizes when saved to an ini file by an application, as we do in ours)
I have added the lines in green, commented out the lines lines in red above. As per comment, sfHeight didn't seem to ever be inScalingFlags so header was never scaled.
I don’t know enough about these flags to say whether my change is correct but it seems to work. I changed Autoscale to change existing node heights as well, and to be aware of the DPI values (call with 1,1 instead of false argument ):
procedure TBaseVirtualTree.AutoScale(const M,D:integer); //was in_dpiChanged:boolean
// If toAutoChangeScale is set, this method ensures that the defaulz node height is set correctly.
// isDPIChnage isTrue, if the DPI of the form has changes
var
lTextHeight: Cardinal;
begin
if HandleAllocated and (toAutoChangeScale in TreeOptions.AutoOptions) then
begin
Canvas.Font.Assign(Self.Font);
lTextHeight := Canvas.TextHeight('Tg');
// By default, we only ensure that DefaultNodeHeight is large enough.
// If the form's dpi has changed, we scale up and down the DefaultNodeHeight, See issue #677.
// Rescale due to PPIchange, up or down issue #677
if (M<>D) then
begin
Self.DefaultNodeHeight := muldiv(Self.DefaultNodeHeight,M,D);
RescaleNodeHeights(M,D);
end
//Rescale due to Font Change, only scale upwards
else if (lTextHeight > Self.DefaultNodeHeight) then
begin
RescaleNodeHeights(lTextHeight,Self.DefaultNodeHeight);
Self.DefaultNodeHeight := lTextHeight;
end;
end;
end;
New protected method RescaleNodeHeights:
procedure TBaseVirtualTree.RescaleNodeHeights(const M,D:integer);
// Scale existing node heights using muldiv, called on DPI changes
var
Node: PVirtualNode;
begin
Node := GetFirst;
while assigned(Node) do
begin
Node.NodeHeight := mulDiv(Node.NodeHeight, M, D);
Node := GetNext(Node);
end;
end;
I can send through my virtualTrees.pas in full when I’m happy with it would welcome feedback on the scalingflags before I do so!
Regards,
Chris
From: Christopher Were [mailto:[email protected]]
Sent: Monday, 9 January 2017 12:13 PM
To: Virtual-TreeView/Virtual-TreeView <[email protected]>
Cc: Chris Were <[email protected]>
Subject: Re: [Virtual-TreeView/Virtual-TreeView] DPI awareness with different monitor DPIs (#677)
Not quite…
Main screen 96 dpi external monitor.
Secondary screen is 192dpi macbook pro screen (running windows within parallels desktop with retina display set to “best for external displays”)
…--- Monitors info ---
Primary Monitor 0 ppi: 96 left: 0 top: 0 width: 3440 height: 1440 (External)
Monitor 1 ppi: 192 left: -2880 top: 0 width: 2880 height: 1800 (macbook)
App starts on main screen, all looks OK:
[cid:[email protected]]
Moving it to higher DPI secondary:
Node text scales correctly, but header text does not. (Column widths don’t scale however, and perhaps should also?)
There are 3 virtual treeviews on this form, left two (vstSystems, vstMaterials) don’t seem to adjust their node height correctly, whilst right one (vstCutting) does, though only after a second click anywhere on the form, i.e. initially after dragging it across its rows are squashed, like the others, but after clicking anywhere or dragging the window position slightly it snaps to correct row spacing…odd…) Nowhere it the pas code can I find any reference to me changing or setting the node height so i am confused as to this behaviour.
(I’ve attached the dfm and pas file for this form in case they are useful. All have autoChangeScale set to True)
[cid:[email protected]]
However on dragging the form back to the 96 dpi main window vstCuttings seems to keep its new expanded nodeheight resulting in bigger than desired line spacing:
[cid:[email protected]]
I did create a test application with two basic virtual stringTrees as a test case and it performs more or less the same; headers do not scale, the node font does, but the node height does not (rows are squashed)
I’M RESENDING THIS VIA MY WORK MACHINE AS COPY AND PASTE BETWEEN THE WINVM AND HOST SEEMS BROKEN….
chris
On 2/01/2017, at 10:45 PM, Joachim Marder <[email protected]<mailto:[email protected]>> wrote:
Will have a look today.
Any news how the GitHub master works for you?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#677 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AXa96zJWrIKFjFSgDBqwluzqWud7H47Gks5rOMdDgaJpZM4LMgPR>.
|
Sorry, did not see any attached files in GitHub.
The best is to send a pull request via GitHub.
Sorry, but GitHub issue comments do not support colors.
Hmm, seems to be a bug in the VCL, I think it should be included. I think i must fetch another monitor and debug this myself. |
|
Yes I'd just attached files to the email, I have some github learning to
do! Changes not ready or properly tested yet either, hopefully tomorrow.
…On Mon, 9 Jan 2017, 21:01 Joachim Marder, ***@***.***> wrote:
project files attached.
Sorry, did not see any attached files in GitHub.
I’ll send through the changes when done for you to review?
The best is to send a pull request via GitHub.
I have added the lines in green, commented out the lines lines in red
above.
Sorry, but GitHub issue comments so not support colors.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#677 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AXa964KEE4JjwY1g1YVu602gPnEkB6Mxks5rQeligaJpZM4LMgPR>
.
|
joachimmarder
pushed a commit
that referenced
this issue
Jan 9, 2017
* TBaseVirtualTree.ChangeScale() now scales the node heights too * TBaseVirtualTree.ChangeScale() now uses DefaultScalingFlags in case of a dpi scaling, just like TControl.ChangeScale() does it. * TBaseVirtualTree.ChangeScale() now calls AutoScale() after calling inherited, to ensure that the Font has been updated.
|
I just committed some changes that I tested successfully with the "Minimal" demo project. Please let me know how these changes work for you. Please attach screenshots if issues still occur. |
|
Thx Joachim, I had just downloaded github desktop and was getting ready to
pull request my own changes, and now i see yours as well. Mine are similar
but I totally ignore scalingflags, and it seems to work OK both with
application startup in different DPI's and with moving controls from screen
to screen. I am not sure about designing at different DPI's, my delphi
forms are designed with pixelsperInch set to 96 even if on the high dpi
monitor and look "normal". Should i fork my changes first before testing
yours?
…On Tue, Jan 10, 2017 at 11:28 AM Joachim Marder ***@***.***> wrote:
I just committed some changes that I tested successfully with the
"Minimal" demo project. Please let me know how these changes work for you.
Please attach screenshots if issues still occur.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#677 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AXa969jMnnU82pjaC2rQ_J1LA_Y0rtdmks5rQrSXgaJpZM4LMgPR>
.
|
|
Seems to be working! :) Have launched the app on my high DPI screen, and on normal DPI, both look good. One issue arises though, if the user saves the column layouts in one dpi, then open the app in another dpi, the columns widths are messed up. In my version I had cached M into fCurrentPPI in the Changescale method if M<>D, as this is typically the new PPI resolution. I then publsih this as a readonly property (currentPPI). That way when the calling application saves and loads the column widths it can do so in a DPI independent way, thus: writing column widths as if we were viewing in 96DPI: if in_tree.CurrentPPI<>1 then
columnWidth := muldiv(Columns[i].Width, 96, in_tree.CurrentPPI) // get dpi of treeview?
else
columnWidth := Columns[i].Width;
Settings.WriteInteger( in_sectionName, columnName, columnWidth );reading column widths for 96dpi and scaling them to current DPI: // Read column size
columnName := in_tree.Name + '.Columns[' + IntToStr(i) + '].Width';
if in_tree.CurrentPPI<>1 then
columnWidth := mulDiv(m_Settings.ReadInteger( in_sectionName, columnName, 0 ), in_tree.CurrentPPI, 96)
else
columnWidth := m_Settings.ReadInteger( in_sectionName, columnName, 0 ); |
I did it like in |
I think this is a separate issue and we should open a separate issue for it. While this one was a bug in Virtual TreeView code, the column stuff is more an enhancement and affects all controls that have columns or grids. So I will close this issue as resolved. |
joachimmarder
pushed a commit
that referenced
this issue
Jan 10, 2017
…led as well if toAutoScale is set.
|
OK, Thanks Joachim.
…On Wed, Jan 11, 2017 at 3:34 AM Joachim Marder ***@***.***> wrote:
if the user saves the column layouts in one dpi, then open the app in
another dpi, the columns widths are messed up.
I think this is a separate issue and we should open a separate issue for
it. While this one was a bug in Virtual TreeView code, the column stuff is
more an enhancement and affects all controls that have columns or grids. So
I will close this issue as resolved.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#677 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AXa96-rQtX0edj-6mjNZxGTPHp7zrfMLks5rQ5b-gaJpZM4LMgPR>
.
|
joachimmarder
pushed a commit
that referenced
this issue
Jan 25, 2017
…) now uses the dpi of the current monitor, not of the default monitor, in Delphi 10.1 Berlin and higher.
joachimmarder
pushed a commit
that referenced
this issue
Jan 25, 2017
…Height based on the Font only, if the paramter isDpiChnaged is False. In case of a dpi chnage the font may not yet be adapted to this.
ValtsS
pushed a commit
to ValtsS/Virtual-TreeView
that referenced
this issue
Jan 25, 2019
…le up and down the DefaultNodeHeight in TBaseVirtualTree.AutoScale(), to which the paramter isDpiChnage has been added. # Conflicts: # Source/VirtualTrees.pas
ValtsS
pushed a commit
to ValtsS/Virtual-TreeView
that referenced
this issue
Jan 25, 2019
…r DPIs): * TBaseVirtualTree.ChangeScale() now scales the node heights too * TBaseVirtualTree.ChangeScale() now uses DefaultScalingFlags in case of a dpi scaling, just like TControl.ChangeScale() does it. * TBaseVirtualTree.ChangeScale() now calls AutoScale() after calling inherited, to ensure that the Font has been updated. # Conflicts: # Source/VirtualTrees.pas
ValtsS
pushed a commit
to ValtsS/Virtual-TreeView
that referenced
this issue
Jan 25, 2019
… DefaultNodeHeight based on the Font only, if the paramter isDpiChnaged is False. In case of a dpi chnage the font may not yet be adapted to this.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
Love the virtual treeview! Even more now I'm using it with "High DPI" on one monitor.
When I drag my running program across to the other monitor all my forms and fonts rescale, but the virtual treeviews do not. my application declares multi monitor DPI awareness. I breakpointed on tbasevirtualTree.changescale and it is getting triggered. I have toAutoChangeScale set on (just been through and set this on all my virtual treeviews)
starting on my high DPI screen (192DPI):
, then dragging to my nomal 96DPI screen:
Note the tabs and button and font within the body of the treeview rescale correctly, but the node spacing and the header size and font do not.
Thanks,
Chris Were
The text was updated successfully, but these errors were encountered: