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?
Related
Within the IDE, when F12 toggles between code and form,
the forms are displayed outside the monitor borders,
and therefore not visible.
This happens after a multi monitor setup has changed,
and the forms no longer open within the available new monitor screen areas.
One way to resolve this is to use the property inspector and
set the Top/Left properties to 4 to make the forms visible.
This is however a lot of work,
especially if many forms and possibly many projects are involved.
Is there a better way to reset the form locations once and for all,
so they are all visible with the new monitor setup?
There is nothing (AFAIK) in Delphi 6 IDE that would help. But assuming you are using Windows, the help is near, (tested on Windows 7):
Right-click on taskbar and select 'Cascade windows', this affects all windows in one go.
or
Alt-Tab to the window, press Alt-Space and then M (for move). Move the window with the arrow keys. This you would have to do seperately for each window.
Close your Delphi IDE. Then, if your current project group file is xyz.groupproj, open the file xyz.dsk with an text editor. Look for section [UndockedDesigner] entry "Count" and change its value to zero.
[UndockedDesigner]
Count=0
That will force all design window positions to 0,0 on your main monitor.
Everything I've found says I can't do this with Delphi 2's TMainMenu but if somebody here has managed it somehow, I'd really like to know the trick. I found code that changes the System menu font size but none that confines the change to only the application. Anyone here know how to do this or do I have to just accept Delphi 2's tiny menu font size that appears on today's large screen monitors? (Moving the app to an upgraded Delphi is not the answer I need ;-)
The only way to achieve per application custom menu fonts is with an owner drawn menu. Delphi 2 does not support owner drawn menu items directly in the VCL properties of a TMainMenu component. This support was introduced only in Delphi 4.
You could still implement an owner drawn menu, but it would involve implementing them using standard Windows API techniques, and handling the required messages on the forms which own the menus involved. It is not especially difficult but not as straightforward as the event based implementation available in Delphi 4 and later.
You can still use a TMainMenu to define your menus but in your application you would then need to programmatically set the owner draw flag on the menu items and handle the resulting messages appropriately. Doing this, you will need to handle all aspects of drawing the menu - you cannot simply set/change the font and leave the system to draw the menu items. You may also need to provide additional handling for any keyboard shortcuts you have set up.
If this is a viable approach then information on implementing owner drawn menus at the API level can be found here.
I'm using FMX framework of Delphi XE6 to develop a webapp for iPad. The form looks extremely large, so that the whole form cannot be shown entirely on 24' TFT monitor. If I want to add control to the form bottom, I have to scroll down first. I found one thing very annoying.
Is it possible to scale the form to 50%? On MacOS, I can easily scale the window of the iOS simulator by pressing ⌘+1.
If you want to fit it too your screensize you schould set the align properties to Client rather then give it a size. This way it scales automaticly to your screensize. If you have more components on your form you should change all of them too align in the way you want and maybe use layouts.
I try to give the user a 'clean and simple' interface by hiding some elements. Only a small arrow denotes that he can expand some part of the main menu bar. When all is closed it looks like this:
When you open all it looks like this:
Each arrow is a SpeedButton thats sits on the left side of a panel. By clicking on the button the Width is toggled between the width of the Speedbutton (closed) and the width of the panel at design time (open). The width of the panel at designtime is stored as a constant. The procedure show_hide_controls handles this:
procedure TCompose_Main.show_hide_controls (key: string; Button: TSpeedButton; Panel: TPanel; width: Int32);
begin
if GPA.iKey [key] = 1
then Panel.Width := width // show panel, set panel to design width
else Panel.Width := Button.Width; // hide panel, set with to button width
Button.Glyph.Assign (nil);
Images_Left_Right.GetBitmap (GPA.iKey [key], Button.Glyph);
end; // show_hide_controls //
This routine is called as follows:
show_hide_controls ('Show Play Controls', // index to panel to show/hide
Enlarge_Play, // Speedbutton requesting the enlargement/hide
Panel_Play, // Panel to show/hide
cPlayWidth); // Width of panel when shown
Now several users report that part of the panel is hidden, like:
It seems that the operating system (Windows 7) plays some tricks with scaling. I'm not able to duplicate this error. Does anyone understand what is happening here? And is there a neat way to program against this in a settings independent way?
Update As GDF rightly pointed out in his answer it has to do with the scaling of the fonts (control panel > Display). This behaves somewhat weird on my machine. Changing it to 150% has a minor impact while changing it to 125% has a major impact. As you might have guessed I tested the first and not the second scaling. Only when a user reported that scaling back from 125% to 100% I could replicate his error on my machine.
I could not find a relation between fonts and the troubles I have as was suggested by several respendents. My system is still suffering from all the tests I did with Courier (not new), Segoe UI, Tahoma and MS Sans Serif :-D. Maybe indirectly because the controls are probably resized to accomodate the text.
How to handle this? I don't know, I'll start experimenting and will let you know if I find something.
Thanks to you all for your help!
If your problem is what I believe, you just stated the answer. Windows 7 plays with scaling certain fonts. When you install Win7 on a PC it checks the size of your monitor and makes the "default" scale setting either 100% or 125% depending on your monitor size. The problem is that at this same time it installs font files onto the computer. It uses a different font file for the different "default" for some of the fonts.
My guess is your app is using MS Sans Serif... this is one of the fonts that gets different font file installs depending on what scale Win7 is using as the (default).
To verify this have your users tell you want scale is set as the default, you can view this by right clicking the desktop and selecting "personalize" then "Display" at the bottom left.
The following link shows you how to change the in-use-font file back to the original
http://www.rlvision.com/misc/windows_7_font_bug.asp
However, I would make an attempt to get off of this font and update the layout elements to work as desired on Win7 as well as past OSes
This is what I think you are dealing with given the limited amount of information you have provided...
Update
Since you reminded me when you mentioned the different looks between 125% v 150%. I just wanted to make sure you were aware that the two different MS Sans Serif files looks better at different scales. One of the font files looks great at 100% and 150% but horrible at 125%. The other font file looks great at 125%, but horrible at 100 and 150%.
I don't quite remember which font file is which, but I know the 2 culprits are
1) SSERIFF.FON
2) SSERIFE.FON
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.