Tom Mueller

11 minutes ago, msohn said:

I spent a major part of the last 4 years making our application here HighDPI compliant. And I ended up using DevExpress TcxImageList exclusively with SVGs...

Thank you for sharing your experience with us.

How did you replace TMainMenu, TPopupMenu, and TToolBar controls? Especially the MainMenu and PopupMenus, as they are widely used in our applications.

44 minutes ago, John R. said:

I've just tested a TcxImageList with a SVG image and used by a TActionList, Speed button and standard menu, and it seems to work just fine.

My little tests with TcxImageList and SVG images shows the lack of scaling on a HighDPI monitor (here scaled to 225%).

Even TcxListView does not scale correctly compared to Delphi TVirtualImageList.

35 minutes ago, Anders Melander said:

If you enable skinning then TMainMenu and TPopupMenu are drawn by DevExpress. They also have treeview and listview controls based on TTreeView and TListView so migration should be fairly easy. TToolbar will have to be replaced but that should be no great loss.

Thank you for the skinning tip. Until now we tried to avoid skinning or styling our applications - but I'll give it a try. 

Just now, Uwe Raabe said:

Compatibility is the limiting factor here.

Yes, unfortunately. cxImageList would be the ideal solution if all controls (not just DevExpress) were supported.

This essentially means that no ImageList can be used for a centralized TActionList. Instead, a TVirtualImageList must be created on each form and associated with the control.

This is a significant limitation of the TImageCollection/TVirtualImageList concept.

I wonder how DevExpress handles this, as the scaling works even when the cxImageList is placed on a DataModule.

Thanks Uwe for pointing me to your blog. The article is very well-written and could help me with implementing centralized image management.

Thank you for your tip. I tested the DevExpress TcxImageList, and it works fine with DevExpress controls. However, it does not support certain Delphi controls, such as TMainMenu, TPopupMenu, TToolBar, TTreeView, TListView and maybe more, which are essential controls for me.

A common scenario in our applications involves using a centralized TActionList connected to a TVirtualImageList on a data module. The actions in the list are linked to controls on different forms (UI).

However, when moving a form to a monitor with a different DPI, the action images do not scale properly. This occurs because the TVirtualImageList is not located on the moved form.

Given that we have several centralized TActionLists in our applications, moving or duplicating them to different forms solely for image scaling doesn’t seem like an ideal solution.

How should centralized TActionLists be handled in HighDPI-supported applications?

13 hours ago, Pat Foley said:

To reveal the markers add to source or set in Object Inspector

BorderWidth = 5

 

That leads to the same result: reducing the size of the sub-control, witch is not an option.

I could live with it, if the size of the sub-control is reduced only in multi-selection mode. But how to figure out if more than one control is selected in the IDE?

Thanks for your effort but you can see the partial markers only because the panel has a border of 1 pixel (due to BevelOuter=bvRaise).

Set BevelOuter=bvNone the markers are hidden completely again.

Thank you for your response.

I noticed that you reduce the size of the sub-control to display the markers correctly.

This works but unfortunately, this approach prevents the sub-control from being displayed at its desired size.

In my case, the sub-control can be of type TEdit, TCheckBox, TComboBox, TDateTime or TMemo, and it is essential that they maintain their correct size at design time.

By reducing the sub-control size, a correct form layout is not possible, and it would look like:

Or, is there a way to reduce the size of the sub-component only when more than one control is selected?

To handle this, I could register my own IOTANotifier with a IOTAWizard to get notified when the control is selected, and then draw the markers manually.

I found some notifiers for the code editor like TNTACodeEditorNotifier but could not find a proper notifier for the form designer.

If anyone has undertaken a similar task, your assistance would be greatly appreciated.

Hallo all

I have a control (TWinControl) that contains an other control (TPanel) and registered it in a package (see demo code in the attachment),

First Problem: When selecting the control in the IDE, the selection markers are only partially visible.

Second Problem: When selecting more than one control, no selection markers are visible at all.

Is this a known problem and are there any solutions for it?

Thanks

Tom

TestSelectMarker.7z

15 hours ago, Der schöne Günther said:

All Windows 11 menus look like this.

Yes, that's something Embarcadero can't change.

But it seems that if the menu is connected to an ImageList Embarcadero uses its own draw method. There are no round corners anymore and the text color does not change to white.

I found a QP issue for the rounded corner as well and I created one for the text color problem:

• https://quality.embarcadero.com/browse/RSP-34597
• https://quality.embarcadero.com/browse/RSP-35800

Hello

I found that the Captions of Delphi's TMainMenu and TPopupMenu are hard to read under Windows 11, if an ImageList is connected to the menu.

Tested with Delphi 10.4 and 11.0.

Windows 10 menu without and with images (ok)

Windows 11 menu without and with image (hard to read black text on dark-blue background)

Can anyone reproduce this behavior?

Best regards

Tom

Set the forms BorderStyle to bsDialog, bsToolWindow or bsSizeToolWin.

Sorry, forgot to mention that.

Yes, OwnerDraw would probably work - if I use a base form for all the forms in an application.

I hoped that there is a more simple way to I just adjust the intent of the caption.

Hello

Has anyone noticed that in Delphi 11.0 the indentation of the form caption is larger than in Delphi 10.4?

Especially under Windows 11 the small indent with Delphi 10.4 is irritating.

IMO Delphi 11.0 makes the better indentation.

Is there a way in Delphi 10.4 to adjust the intent of the form caption (without using Styles)?

Best regards

Tom

After installing Delphi Rio Update 2 with the WebInstaller, I realized that some core files are dated from 08. July 2019 00:55 and others from 30. July 2019 15:55.

The build number is 26.0.34749.6593 and as far as I remember this build was release on the 08. July 2019.

So, how can it be that a lot of core files, like BDS.exe and BPLs have a newer date than the release date but the same build number?

Any Ideas?

4 minutes ago, Dalija Prasnikar said:

Well, MDI applications were deprecated a long time ago and Delphi IDE is seriously lagging behind in getting proper high DPI support. What I mean is that actively developed applications should be eventually updated to fully and properly support high dpi and not rely on this fix. I know, it takes time to do so...

Yes, I agree - it would be the right way to update all applications to fully support high dpi. For our applications this will take probably 1-2 years and some money that our customers won't spend..

9 minutes ago, Dalija Prasnikar said:

Now, it is much clearer. Can you please add that picture to your QP report.

I will do so. Thank you for comments!

2 hours ago, Dalija Prasnikar said:

Maybe, but this setting is merely a quick fix for seriously outdated applications. I am not sure how much sense it makes to add such support in IDE.

I agree, but what means seriously outdated applications - all MDI applications and Delphi IDE?  😉

2 hours ago, Dalija Prasnikar said:

If I understood you correctly you would like to add gdiScaling element automatically when "System Aware" option is selected, but that might have negative impact on some applications that use such setting. I am saying might because I don't have any particular example where it will fail, but if that setting would be completely compatible, then MS would not introduce additional flag, they would just apply enhanced scaling to all applications with corresponding dpiAware  or dpiAwareness settings.

No, it should be an additional item in the DPI awareness drop down box. I called it "System Aware (enhanced)" - but I see it makes it clearer if it is named "GDI Scaling".

Delphis DPI Awareness modes and its Manifest entries would then look like (simplified):

16 hours ago, Dalija Prasnikar said:

To achieve what you want you can also use custom manifest instead of automatically generated one.

Yes, but it would be easier and more logical if it would be an auto generate option.

16 hours ago, Dalija Prasnikar said:

Also, your request is a bit confusing - System (Enhanced) scaling in application properties dialog has nothing to do with System Aware setting you can choose for manifest. Auto generated manifest sets only dpiAware and dpiAwareness elements and you want ability to include gdiScaling element.

"System Aware" in Delphi should corresponds to "System" in application properties (<dpiAwareness>system</dpiAwareness>). 

So I named it "System Aware (enhanced)" that should correspond to "System (enhanced)" in application properties (<gdiScaling>true</gdiScaling>)

Most "older" applications do not have full support of High-DPI scaling. To enhance the appearance of these applications Microsoft added the gdiScaling option in Windows 10 Creators Update (1703) .

  <asmv3:application>
    <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2017/WindowsSettings">
      <gdiScaling>true</gdiScaling>
    </asmv3:windowsSettings>
  </asmv3:application>

In the compatibility settings of the windows property dialog of an application this is marked as "System (enhanced)"

Delphi manifest option do not support this scaling mode at the moment.

Our Build-tool sets the gdiScaling option in the manifest - but a build inside the IDE with gdiScaling is not possible!

I also added a feature request in QP: https://quality.embarcadero.com/browse/RSP-24175.

If you miss this option too - please vote for It.

Best regards,

Tom

Hi Andi

Thank you for providing us your tools! dfmCheck is a very useful tool - especially for large projects with a lot of forms.

I encountered one problem for projects with FastReport. 

FastReport writes the main component TFrxReport into the pas file - all sub-components are only stored inside the dfm without a reference in the pas file.

Unfortunately our projects use a lot of FastReport and therefore a compilation with your generated special unit is not possible.

My question: do you see a possibility to exclude units or classes (actually only TFrxReport) from the dfmCheck - or even a switch "- Ignore FastReport"?

Best regards,

Tom

Yes, I've seen that - "-VN = TDS symbols in namespace" but what does it mean?

Hello 

Some questions:

• Can somebody explain what the compiler switch -VN is used for? 
• Where can it be set inside the IDE (Delphi 10.3.1)?
• Why is this switch the default Delphi 10.3.1 setting for new projects?
• Why is this switch doubled when the -VT switch is set inside the IDE? (you can see the command line in the "Build" tab of the "Messages" tool window)

Any hints would be appreciated!

On 2/23/2019 at 1:02 AM, Remy Lebeau said:

Just how many resource strings are you dealing with?

There are not so many resource strings.

In my DevExpress package I include 45 units with "resourcestings" in it - that will extracted about ~5000 resource stings.

PS: Sorry for the delayed answer.