OpenDCL 9 introduces automatic scaling of controls, (so that controls adapt to the display scale). Which is great.
Unfortunately,images for controls eg Picture Boxes and Graphic buttons are not automatically scaled, by design (as it can result in poor quality images).
So if anyone has their Windows Display settings to anything other than 100% for instance 150%, even if its the default/recommended setting for the display - a size mismatch results between the images and the controls.
Does anyone have any thoughts about how to approach this issue?
For a Picture Box, I wonder if turning on Auto Size (http://www.opendcl.com/HelpFiles/index.php?page=Reference/Property/AutoSize.htm) could be used as a workaround.
I've now added for the next build automatic scaling of all position and size parameters to picture box methods. This is consistent with other controls, which treat all parameters and properties as "device independent pixels", scaling them by the same amount as control sizes are scaled before applying them.
Images themselves are not scaled, but at least the LoadPictureFile (http://www.opendcl.com/HelpFiles/index.php?page=Reference/Method/PictureBox/LoadPictureFile.htm) method enables stretching to fit the control.
Do you think this is enough to make ODCL 9 useable for you?
The "LoadPictureFile" method (with stretch) will do very nicely and would indeed make ODCL 9 usable.
As ever, thank you very much indeed. :)
Please test with 9.0.1.2 and let me know whether there are any remaining showstoppers for you.
Thanks Owen, you're so onto it.
Just a wee thing though, the Studio Help About still shows 9.0.1.1, but the runtime shows the new 9.0.1.2
No biggie.
Strange that the version didn't get updated. Nothing changed in Studio for this update, so no harm done I guess.
Quote from: owenwengerd on April 03, 2018, 03:31:32 PM
Please test with 9.0.1.2 and let me know whether there are any remaining showstoppers for you.
Thank you Owen, I will get back to you eitherway as soon as possible.
With thanks, there are two show stoppers in 9.0.1.2. (They are presumably related).
Working on the assumption the Windows display setting is set to 125% on a 1920 x 1080 resolution screen:
1. (dcl-GetScreenSize) will still return the same number of pixels for a display setting of 100% eg (1920 1030). But as far as OpenDCL runtime is concerned the actual number of pixels is stopped down to (1920/1.25 1030/1.25) ie (1536 824). So if a form is shown with PositionX and PositionY specified - It will be shown in the wrong place relative to the screen. This obviously affects other form positioning functions too.
2. Modeless forms are getting unnecessarily scaled up in size. (introduced in 9.0.1.2?). For instance if the form is designed in OpenDCL Studio to be 400 pixels wide. At Runtime it is drawn at (400 x 1.25) ie 600 pixels wide (dcl-Control-GetWidth will return 600). So its actually overly large for the display. It presumably should remain 400 pixels wide due to the stopped down display scaling at Runtime, see item 1).
I've attached a screenshot which demonstrates what is happening to a (non-resizable) modeless form .
The goal is to make all reported positions and sizes be in "display independent pixel" form. Therefore, I suppose that (dcl-GetScreenSize) should report 1536x824 in your case. An argument could be made here that (dcl_GetScreenSize) should return unscaled pixel size, but I've changed it now for the next build. Let's see if any problems crop up, and if it solves the problem you have.
I just did a quick test with a non-resizable modeless form set to width 400, and it seemed to work as expected. Can you provide exact instructions to reproduce that case? After displaying a form with width 400 at 125% scaling, (dcl-Control-GetWidth) should return 400 even though it is actually displayed 500 pixels wide.
Thank you for sorting (dcl_GetScreenSize). Fingers crossed it doesn't cause more problems for you.
I've revisited my code. Regarding my modeless forms. I see now what has occurred. My OnInitialize events utilised (dcl-form-resize ...). It is this which is resizing the form incorrectly ie (dcl-Form-Resize <CONTROL> 300 300), incorrectly draws the form at a width and height of 375 (assuming 125% Display Resolution).
Something else occurs to me - What do you think about a new function? Something like (dcl-GetDisplayResolution). In this case either returning 125% or (perhaps better) 1.25. Then at Runtime based on that information, we can optionally programmatically replace images in the project's Picture Folder with a batch of larger ones. The end result hopefully being more or less correctly sized pictures for the Graphic buttons (and possibly Picture Boxes).
Good catch, I've now fixed (dcl-Form-Resize) and (dcl-Form-CenterAndResize).
I've considered adding some function for returning the display scaling value, and I would have added one if it were as simple as adding one global function. Unfortunately it would need to be a member function of the form class, because display scaling can be different for each monitor, and display scaling of a form thus depends on which monitor it is displayed. For the same reason, there would need to be an event added for responding when display scale changes (e.g. when a form is dragged to a different display). It may ultimately have to be done, but I'd like to avoid adding more complexity as long as possible, at least until I fully understand the requirements.
Hi Owen,
Thanks for 9.0.1.3. Unfortunately something is still awry for me with (dcl_GetScreenSize).
Working on the aforementioned resolution (1920 1030) and a display setting of 125%:
- My expected return would be (1536 824). Assuming the calculation (Width/1.25 x Height/1.25). This result works with dcl-Control-SetPos etc routines.
- My actual return is (1288 2400). Which can be reverse engineered to ((Height x 1.25) x (Width x 1.25)). So height and width are reversed and the resolution has gone the wrong direction.
Oops, seems I got some wires crossed. It is fixed now for the next build.
in the past, this form was shown in this way (01)
. . .
while now it is shown in this other wrong way (02)
. . .
I am using
OpenDCL.Runtime.9.2.0.3
. . .
what have I to do ?
with OpenDCL.Runtime.9.2.0.3
(dcl_project_load "@dcl-select-color" t)
(dcl_form_show "@dcl-select-color" "frm_sc")
I have attached the file below @DCL-SELECT-COLOR.odcl
If you open this file in the OpedDCL studio, it has the right look,
but it doesn't happen the same when you try to show it in Acad . . .
I think the solution is to draw the color swatches at runtime using the picturebox methods, instead of displaying a pre-made image. There are functions like XPixelsToTwips (http://www.opendcl.com/HelpFiles/index.php?page=Reference/Function/XPixelsToTwips.htm) that can be used for calculating the ratio of pixels to dialog units, but I think in this case you only need to evenly divide the overall size of the picturebox.
I was hoping there was a solution that
would make the new version of the OpenDcl runtime
fully compatible with previous ODCL files.
Couldn't there be an option to turn off
the automatic resizing of the controls?
. . . it seems that there is a lot of people interested in this topic !
I've also been trying to get a solution to this but with no luck.
Quote from: ScottBolton on November 16, 2023, 03:25:55 AM
I've also been trying to get a solution to this but with no luck.
unfortunately it seems that
it is not possible or it is considered useless
to modify the behavior of this automatic scaling of controls ...
it seems that this problem has been solved!
But Owen didn't tell us!
Thanks a lot anyway !