We further spend a considerable amount of time and found a case on TParamListBox and one on TAdvTreeComboBox.
We applied improvements that will be included in the next release.
Great! I'll wait for the update (hope soon), and on that other issue with the LED TvrIndicator with it (the RTL) sending it a negative value, would you be willing to give embarcadero permissions to use a version (or is a trial available they can use). It may be C++ RTL specific?
Embarcadero has access to our products
I tried the latest updated and the TParamListBox entry issues with spinner and edit fields is fixed (if you want me to nit pick a little the entry field cuts off just a tip of the first letter as it goes to widen the field, but it's not really a problem). However the line spacing issue moving from 250% to 100% still exists as shown in the picture from 17 days ago but it's not a critical issue. So TParamListBox is now usable for production release.
The main issue left (out side the potential RTL issue) is with the AdvTreecomboBox. It still too huge! I've attached pictures this time, one from the 100% screen and the other from the 250% screen (you'll see it is way out of whack).
This is the 100% screen (I put it on the bottom like the 250% screen which I had to do for it to even fit).
This is on the 250% screen - note the width and height are WAY too big (it should be the width of the combo box like on 100%).
The interesting thing is it looks like it's 2.5x too big which matches the 250% (it's like it sized to the correct size some place then sized a second time which made it 250% too big). I don't believe it was like that before fixing the enter/escape key issues, but I can be wrong.
What Delphi version is this?
What form designer DPI setting you have in your IDE?
Do you start the app on the 250% screen or the 100% screen?
C++Builder 11.3 - It doesn't matter, I tried starting on one and moving to the other, in this last case the app started on 100% opened that dialog at 100%, dragged over to 250%, opened the dropdown. DPI Awareness is "Per Monitor v2", under Appearance no custom styles are checked, default style is "windows".
I asked:
What form designer DPI setting you have in your IDE?
DPI Awareness is "Per Monitor v2", under Appearance no custom styles are checked, default style is "windows".
The IDE itself is running on the 100% screen.
The form that opens is opened from a main form. Do you need a sample project?
As I cannot reproduce this here. Please provide a sample source project + exact steps with which we can reproduce this here.
Here is the file showing the issue (under the dialog test button) - it seems to be caused by the resize handler that makes the combo dropdown same size and combobox. Maybe a new option is needed for the control to do that automatically? Or what is the proper way to prevent issues?
TestHighDPI_c_2.zip (84.1 KB)
I'm sorry but we cannot see a problem.
Our compiled test app can be downloaded here:
https://download.tmssoftware.com/download/AdvTreeComboBoxTest.zip
You didn't put in the FormResize on the form:
void __fastcall TForm2::FormResize(TObject *Sender)
{
if (ComboBoxCategory) {
ComboBoxCategory->DropWidth=ComboBoxCategory->Width;
ComboBoxCategory->DropHeight=ClientHeight-(ComboBoxCategory->Top+ComboBoxCategory->Height);
}
}
This ensures the dropdown makes the same width and the comboxbox itself (also allows the height to change). That is what causes it, which is why it maybe should be an option on the control or document the proper way to do it?
One way it could be an option for the width is if -1 means use size of combobox field width. BTW, I also tried using "ondropdown" but it still too large.
Have you figured out a workaround or will it have to wait for an update?
It is your code that is wrong. DropWidth & DropHeight properties are the expected values at 100% DPI.
If you set this at runtime, you should take the current DPI in account if you want this to match the size.
This code makes this work correct at runtime:
procedure TForm2.FormResize(Sender: TObject);
var
dpi: cardinal;
begin
dpi := GetDpiForWindow(Self.Handle);
ComboBoxCategory.DropWidth := Round(ComboBoxCategory.Width / (dpi/96));
ComboBoxCategory.DropHeight := Round( (ClientHeight-(ComboBoxCategory.Top+ComboBoxCategory.Height))/((dpi/96)));
end;
Other than this, we added the enhancement that when DropWidth = 0, it will automatically take the width of the control.
The workaround works - I show the c++ version below. However, there is another issue with the tree combo drop down when DropPosition is set to dpAuto and on the 250% monitor it chooses to open up instead of down so you can't see the items in dropbox. On the 100% screen it opens up if would go beyond the bottom. My dialog was almost the size of the 250% screen, the resize process below was used, it opened up instead of down. Any workaround or fix for that?
void __fastcall TEntryForm::FormResize(TObject *Sender)
{
// adjust tree size on catagory box
if (ComboBoxCategory) {
double dpi = GetDpiForWindow(Handle);
ComboBoxCategory->DropWidth=int((double)ComboBoxCategory->Width / (dpi/96));
ComboBoxCategory->DropHeight=int(double(ClientHeight-(ComboBoxCategory->Top+ComboBoxCategory->Height))/(dpi/96));
}
}
FWIW, it seems the TAdvTreeComboBox with the resizing code gives an "External exception C06D007F" on Windows 8.1 (x64). It doesn't occur on Windows 10 or 11 (I didn't try WIn7). It does it when opening the form and then when resizing the form. So I presume that control because the dropdown menu item is not resized.
Is it your code from the previous post that causes this, i.e. setting the DropWidth & DropHeight?
If not, do you have more details?
It just needs a try / catch around GetDpiForWindow