-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PSX preparations #1786
PSX preparations #1786
Conversation
…dows It is now possible to store the window coordinates of resizable exterior subwindows. This is opt-in so you have to register the exterior subwindow via PS_InitCoordinates in addition to the main window. As not all subwindows might want to be saved, we now have to check in PS_StoreWindowCoordinates if storing is requested or not. It is not clear why MoveSubWindow needs the points -> pixel conversion.
For a future application we want to read that back.
…rs to allow passing in a check function If the check function returns 1 we throw an SFH_Assert.
We support more than analysis function tests since 627725e (Generalize PSQ_TestOverrideActive and MSQ_TestOverrideActive, 2021-10-19).
…eResults This is much cleaner than duplication the wave getter logic.
By not using the convenience wrapper SFH_ResolveDatasetElementFromJSON we can issue better error messages for multiple datasets.
93f9453
to
80da1fd
Compare
@MichaelHuth Please review, thanks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only minor stuff.
@@ -136,7 +136,12 @@ static Function PS_ApplyStoredWindowCoordinate(variable JSONid, string win) | |||
|
|||
AssertOnAndClearRTError() | |||
try | |||
MoveWindow/W=$win left, top, right, bottom; AbortOnRTE | |||
if(IsSubWindow(win)) | |||
// correct for pixel/points confusion |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect the reason is:
"By default, panels are drawn using pixels if the screen resolution is 96 DPI but using points for higher-DPI settings. This gives backward compatibility on standard screens and reasonably-sized controls on high-resolution screens."
from DisplayHelpTopic "Control Panel Resolution on Windows"
from DisplayHelpTopic "Control Panel Units"
at 100% GUI scaling in windows print screenresolution
results in 96 in IP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But why is that only relevant for exterior subwindows?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think because MoveWindow coordinates are always in "points".
Whereas MoveSubWindow are in "points" or "control panel units". If it is "control panel units" then the mentioned distinction for screenresolution == 96 dpi -> pixels, otherwise points kicks in.
What is a bit unclear to me is, that the MoveSubWindow docu states: "coordinates are taken to be fixed locations measured in points, or control panel units for control panel hosts".
Because according to that, it should be like:
if(IsControlPanelHost(subWin))
// "control panel units"
if(screenresolution == 96)
return pixels
else
return points
endif
else
return points
endif
Ragendiff:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can move the points/pixel origin question to an issue, as you have visual verification that your code shows correctly.
@@ -136,7 +136,12 @@ static Function PS_ApplyStoredWindowCoordinate(variable JSONid, string win) | |||
|
|||
AssertOnAndClearRTError() | |||
try | |||
MoveWindow/W=$win left, top, right, bottom; AbortOnRTE | |||
if(IsSubWindow(win)) | |||
// correct for pixel/points confusion |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think because MoveWindow coordinates are always in "points".
Whereas MoveSubWindow are in "points" or "control panel units". If it is "control panel units" then the mentioned distinction for screenresolution == 96 dpi -> pixels, otherwise points kicks in.
What is a bit unclear to me is, that the MoveSubWindow docu states: "coordinates are taken to be fixed locations measured in points, or control panel units for control panel hosts".
Because according to that, it should be like:
if(IsControlPanelHost(subWin))
// "control panel units"
if(screenresolution == 96)
return pixels
else
return points
endif
else
return points
endif
No description provided.