Jump to content

Tom Mueller

Members
  • Content Count

    19
  • Joined

  • Last visited

Posts posted by Tom Mueller


  1. 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.

    Menu_Win11.png.39bded0c10c78335f0ef4298c7b2f84a.png

     

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


  2. 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.

     

    Menu_Win10.png.a3b50c4a66976ad56f25f0eac39dfac1.png

    Windows 10 menu without and with images (ok)

     

    Menu_Win11.png.50bc9eb13a100efca10244921932aaf8.png

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

     

    Can anyone reproduce this behavior?

     

    Best regards

    Tom

     


  3. Hello

     

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

    image.png.e4f98b5042ca7e565d1b7d6d315ca610.png
     

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

    image.png.52a4a700ea2ad733353b0d72eaf7fe87.png

    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

     


  4. 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?


  5. 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!


  6. 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):

    1317141765_Delphi_Manifest_GDIScaling.thumb.jpg.6121eaf9367e8be6eaf9c674d7d737cb.jpg

     

    • Like 3

  7. 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>)

     


  8. 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)"

    Windows.thumb.png.89122163b7bf2aa466722986ef6a764d.png

     

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

    Delphi.png

     

    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

    • Like 2

  9. 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

     

     


  10. 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!


  11. Yes, I tried this approach - but it is a clumsy way.

    - limit the units by try_and_error per package

    - merge the resulting drc-files into one drc-file per 3rd party for the translation tool

     

    Actually Delphi raises the error after the creation of the drc-file (so the linker does its job with the drc-file but then raises E2621 when trying to create the bpl-file).

    Our automated building process will stop because of this error. 

     

    I wonder if there is an option to tell the linker to just extract resources?


  12. Hi

     

    For our project translation tool I extract all resourcestrings from 3rd party components into drc-files.

    This is donne by creating a temporary package with all units containing resourcestrings and then compile it with the --drc switch.

    Until Delphi 10.2 this worked perfectly.

     

    With Delphi 10.3 some of these packages cannot be created anymore. Delphi will raise an "Error: E2621 Export table in output file too large: exceeds 65536 limits"

    There is a bug report about this error https://quality.embarcadero.com/browse/RSP-22698 but it is marked as "Resolved" "Workes As Expected".

     

    Instead of a package project I tried to include all units into a console application - this compiles without a problem - but not all resourcestrings are extracted into the drc-file.

     

    To my question:

    Anyone knows another way to extract all resourcestrings int a drc-file from 3rd party source files?

     

     

     


  13. Yes - some properties get refreshed during typing and some not.

     

    So far I checked the properties for some basic components that do not refresh:

    - BevelWidth

    - Top

    - Left

    - Width

    - Height

    - Tag

    - ImageIndex

    - Margins (Bottom, Left, Right, Top)

    - Constraints (MaxHeight, MaxWidth, MinHeight, MinWidth)

    - TabOrder

     

    It seems most numeric properties (beside the Name property) do not fire a change event when loosing the focus.

     


  14. When changing a property value, for example the name property of a TLabel in the object inspector and then directly select another component on the form, the changed name value is not saved.

    Only pressing the Enter key or changing to an other property saves the changed value.

     

    Steps to reproduce:

    1. add two TLabel on an empty form and select one
    2. change the name of the label without pressing the enter-key
    3. select the second label
    4. select the first label again -> your changed name is gonne!

     

    In Delphi 10.2.3 Tokyo this error was not present. 

     

    It is not a killer bug but a very annoying issue! 

    Can anyone reproduce this issue?

     

    PS: I reported the bug on https://quality.embarcadero.com/browse/RSP-23694

×