I submitted a bug (RSP-30892) to Embarcadero over 1.5 years ago (since Rad Studio 10.4) regarding the following issue:
TCheckBox is scaling when it shouldn't when Windows 10 is set to 150% scaling. The form property is set to Scaled=false, the checkbox still scales 150%. Other controls conform to the form property.
While I have patiently waited for a fix on their end, it has yet to occur. I have tried to override the PixelsPerInch property of the control, but it is ignored.
The big question: Has anyone had any success with a work around, or, a way to override this behavior?
In case it is needed, here is how to reproduce:
Create VCL C++ Forms project.
Set form's "Scaled" property to false.
Add a TCheckBox to the form.
Apply a style to the application in the project options (like Windows 10 Dark).
Under project options->Packages, turn off dynamic RTL in linker. Turn off runtime packages.
Under project options->Application, Manifest, check Enable Runtime Themes and set DPI awareness to Per Monitor v2.
Run on a Windows with scaling set to 150%.
There is another bug report according to which this works as designed: https://quality.embarcadero.com/browse/RSP-24216
Scaled only affects the font size, not the boxes. To fully prevent scaling you must set DPI awareness to "None" in Options -> Application -> Manifest.
You have set the DPI awareness to "Per Monitor v2", which will not work.
When I set DPI awareness to "None", the entire form is scaled. So it seems there is intentionally no way to leave the form small.
Related
I have encountered a problem with Delphi's multi monitor high-DPI support that I would welcome any insights you might have. I am using Delphi 11.2 patch 1 on a 5K monitor with Delphi's form designed set to Automatic (Screen PPI)
I have a small test project with a TDBAdvGrid and a TDBNavigator at the top of the form and a separate Tframe at the bottom of that form added at design time also having a TDBNavigator and a TDBAdvGrid on it. When I run the program initially it all looks fine.
As I said,I am designing on a 5K monitor (5120x2880) at 200% font scaling and I have a second monitor attached (1920x1080) at 100% font scaling. If I drag the form onto the second monitor the grid and navigator on the form appear to respond nearly as they should (just doesn't get the column widths quite correct) but the grid and the navigator in the TFrame don't.
Then if I drag the form back to the main monitor the TFrame is even more messed up
Do you have any recommendations on how to handle this? Should I be doing something with the main form's onBefore/OnAfterMonitorDPIChange events?
This high-DPI stuff all seems very much work in progress. And if I wanted to persist the column widths in an ini file, how would that work? Would I have to save it separately for each monitors PPI settings?
Running windows 10 21H2. Just upgraded to Delphi 11.2 (from 11.1).
Speedbuttons (with Flat=False) do not show the button rectangle at design time. It does appear at runtime.
Most/all of our VCL projects have an empty style name. I have noticed that if I set the Stylename for the button (or even the form), then it shows normally. But is this the best way of handling it? Is there a global setting somewhere that can restore "normal" behaviour?
In 11.2 the Form Designer Options have a new option Mimic the system style, which is active by default. Disabling that should solve your problem.
Form Designer Options
As per my previous question (Delphi 6 support for toolbar and menu icons with alpha channel transparency), we are updating a legacy application developed in Delphi 6 to support Windows Visual Themes by including a Manifest. This has worked well and we have the majority of controls adopting the Windows visual theme correctly.
However, we do have a problem with TDateTimePicker behaving in a slightly odd manner. We have the form colour set to white (RGB 255/255/255) and the input box for TDateTimePicker is not visible on the form until it is clicked into and has an entry in it. Please see screenshots below:
Changing the form colour to grey, we can see that the box is there when not selected, it just has no border drawn around it:
We have been unable to find a property that will change this behaviour. Can anyone shed some light on why this might be occurring, what property needs to be changed, or another method we could possibly use to resolve it?
I`m using Delphi XE3. When using the custom styles (e.g. Carbon) that are available since Delphi XE2, there is a visible white flickering when moving the mouse over the borders of the TComboBoxEx control (MouseExit/Enter).
Steps to reproduce: Create a new VCL Forms app, drop a TComboBoxEx on the form, select e.g. Carbon in project options --> Application\Appearance and start the application
Is this a known problem/bug and is any solution known?
Thank you
This Border flicker issue is not the product of using Delphi VCL Styles.
(The same problem can be observed without using VCL styles)
The culprit here is the Desktop Window Manager which is an essential part of Windows Visual Styles and Themes.
The reason why you are seeing this issue and others may not, is because you have at some point changed the default Windows Theme (aero theme) or you've changed a specific Visual effect property of your selected theme.
You perhaps also have intentionally or unintentionally disabled the Desktop Window Manager since it runs as a Windows service.
To be more exact, the issue is resolved if you enable the Desktop composition feature.
This feature is only available in Aero themes(default) but not in Basic or Classic, tho sometimes it can appear to be available even when it is not.
Control Panel --> System --> Advanced System Settings --> Advanced --> Performance Settings --> Visual Effects
When desktop composition is enabled, individual windows no longer draw
directly to the screen or primary display device as they did in
previous versions of Windows. Instead, their drawing is redirected to
off-screen surfaces in video memory, which are then rendered into a
desktop image and presented on the display.
As you might have guessed, the functionality of this function is to basically act as a Buffer which in a very neat way explains the border flickering when this option is turned off.
Important Fact
Desktop composition feature can only be enabled if your current theme is an Aero theme and using Windows Visual Styles.(It is by default enabled for every Aero Theme)
Visual Styles are enabled by default in Aero Themes, you can check that it is enabled by making sure that the Use Visual Styles on Windows feature is enabled in the Performance Settings. When the Classic or Basic Themes are in effect the desktop composition feature is never in play and cannot be enabled. (Classic theme has been deprecated since Windows 8)
Sometimes in Windows 7, the Desktop composition feature can show itself in the Performance Options even when using a Basic or Classic Theme but do not be fooled, this is an internal bug.
Steps to reproduce this bug :
Start With default Windows Aero Theme
Go into Performance Settings as described above
Uncheck the Desktop composition from the list
Mouse over the border of TComboBoxEx, it should now be flickering as
you enter/leave.
But what happens if I uncheck Use Visual Styles on Windows checkbox? Why does this solve the flickering issue?
This will cause the Desktop Window Manager(DWM) to disable themes all together for all Windows Controls. What this means is that controls will be drawn using an older rendering style as oppose to using the newer Aero rendering style.
You can turn off Visual Styles for individual controls without turning it off globally with the following method SetWindowTheme(Handle, nil, nil)
This is also why the flickering issue for TComboBoxEx border is resolved when Visual Styles are disabled.
It's also worth mentioning that since Windows 8 you cannot disable Visual Styles anymore because as I said the Classic theme is deprecated.
Regarding the solution, I don't think you've got much of a choice really. Given how much freedom is left to the user when it comes to modifying the visual effects of Windows themes, this sort of thing is bound to happen. At least you can be certain that this issue does not happen on the default Windows Theme.
Have you seen this?
I have a little utility application (for easy load / test xml generation from CDS and/or DBGo), and I had put some buttons (the poorest button of all, TButton) to trigger some actions.
I never paid attention to appearance, because I'm the only one that uses it. So today I added a new button, and they appeared different from the others in designer - but not when running. It's just an copy and paste process (change the button name, caption and event - the rest is equal to the origin).
When I looked the other buttons have an grey gradient and round corners, the button I copied and pasted not (just a bare rectangle). When running all buttons where just bare rectangles.
So I discovered that on designer, W7 and delphi are applying themes. On running, they are obeying the Project/Options/Application/Enable runtime themes flag.
This is annoying. There's a way to make Delphi doing that obeying the project options flag on forms designer?
(Or even manually if is not possible to automate that)?
EDIT:
The toolbars on the form are from CNWizards ;-)
EDIT II:
Apart of disabling themes for the IDE executable, all buttons get themed equally if the form (or project) is reloaded. But it's really weird.
If you want to enable/disable themes in the IDE, then open the properties of bds.exe, select the 'Compatibility' tab, and make sure that the 'Disable visual themes' checkbox is unchecked/checked.
Programs that you run from the IDE will inherit the compatibility settings of the IDE.
Delphi IDE itself is an application and the way the designer draw the form is using the setting for the IDE application (delphi32.exe or bds.exe's compatibility settings) so the answer is no. The default behaviour is different between IDE versions, for eg. the opposite behaviour (not drawing themed) happened in past.