A.M. Hoornweg

One observation: 

in unit Vcl.Forms there's an optimization in tCustomForm.WMDPICHanged which ensures that a form is only re-scaled when Message.YDPI is unequal to fCurrentPPI.

Assuming that fCurrentPPI may not be perfectly reliable, I have removed that optimization just for testing.  And bingo, my form now appears to re-scale properly every time.

    //unit vcl.forms.pas method tCustomForm.WMDPICHANGED
    
    if (* (Message.YDpi <> fCurrentppi) *) and Scaled then
    begin
      DoBeforeMonitorDpiChanged(fCurrentppi, Message.YDpi);
      OldPPI := fCurrentppi;
      ScaleForPPIRect(Message.YDpi, Message.ScaledRect);
      FCurrentPPI := Message.YDpi;
      fPixelsPerInch := FCurrentPPI;
      DoAfterMonitorDpiChanged(OldPPI, FCurrentPPI);
    end;

Also I've found out that constraints may be problematic in Delphi.

Normally, when a form is dragged to a new monitor having a different scaling factor and its center reaches the new monitor, Windows sends a wm_dpichanged message to the window's wndproc to inform it of the new resolution and also gives it a pointer to a rectangle containing a proposed new position and size. The form must then redraw itself using the proposed position and size to ensure that  the scaled window is definitely on that new monitor.

However, constraints in VCL components can enforce size limits to components and to the form itself.  So it may very well be that after the positioning and resizing, the center of the form is suddenly back on the previous monitor ...

Hello World,

I'm trying to debug some dpi-awareness problems in an application of mine (using Delphi 11 on a Windows 10 X64 VM).  I have a 3-screen setup with different scaling factors for testing (from left to right: 300%, 100% and 175%). I test dpi awareness by dragging my main form between these screens. 

Most of the time the re-scaling kinda works (albeit slow), but sometimes things get wonky and I wanted to know why. This main form of mine is a rather complex one and it needs some time to redraw when the screen DPI changes. I'm trying to reduce that amount of time but in this case the VCL components themselves are kinda sluggish.

For diagnostic purposes I have overridden the method tForm.DoAfterMonitorDpiChanged() to output some debugging information and the outcome puzzles me.

procedure tMyForm.DoAfterMonitorDpiChanged(OldDPI, NewDPI: Integer);
begin
  inherited;
  OutputDebugString(Pchar(Format('Currentppi / Pixelsperinch  %d / %d',[currentppi, pixelsperinch])));
end;

Most of the time the values of CurrentPPI and PixelsPerInch are identical and reflect the value of the screen where the form was dragged to, but occasionally they go out of sync. 

When that happens, one of the two contains the DPI of the new screen where I moved the form, whilst the other one reflects the dpi of the screen where the form used to be. This happens especially if the dragging was "fast".

When I look into the source code of unit vcl.forms, I see that the developer usually sets both properties to the same value. So I assume this behaviour to be a bug. Also, I fail to understand why tForm needs both these properties if they are intended to always be the same value. Unfortunately I can't consult the on-line help because https://docwiki.embarcadero.com has been down since yesterday.  Can anyone shed some light to this, and maybe try to reproduce the behavior?

It's been four months since this thread was created, still no bookmarks tool in sight 😞

5 minutes ago, angusj said:

Delete this line. It's only (sort of) useful for images without alpha transparency.

Thank you! Now it works !

Hello all,

I have a tImagecollection with square transparent PNG images at 256x256 size which I want to downscale smoothly. The collection's interpolation mode is set to icIMModeHighQualityCubic.

I notice that tVirtualImage gives much smoother image quality at 32x32 than tImage if I manually downscale the image using tImageCollection.GetBitmap().   

I would very much like to get to the bottom of this.

This is the code I use to manually extract and downscale an image from tImagecollection.

Parameter "Targetimage" is just a TImage on some TPanel on a TForm. Am I doing something wrong?

procedure LoadImageFromCollection(TargetImage: tImage; ImageName: string; Collection: TImageCollection;
  DesiredHeight: Integer);
var
  tb: tbitmap;
  h,idx: Integer;
begin
  idx := Collection.GetIndexByName(ImageName);
  if idx > -1 then
  begin
    h:=desiredHeight;
    if TargetImage.AlignWithMargins then
      h := h - TargetImage.Margins.Top - TargetImage.Margins.Bottom;
    TargetImage.Height := h;
    TargetImage.width := h;
    TargetImage.Transparent := True;
    tb := Collection.getbitmap(idx, h, h);
    try
      tb.AlphaFormat := afDefined;
      TargetImage.Picture.Bitmap.Assign(tb);
    finally
      tb.free;
    end;
  end;
end;

19 hours ago, David Heffernan said:

For example this 10 year old answer has example code

 

https://stackoverflow.com/a/5133222/505088

 

I think I've made a few minor improvements to this over the years, but the code here works fine. 

Interesting!  I'll take a good look at that, thanks for pointing it out!

3 hours ago, David Heffernan said:

Not if the comctl v6 manifest hasn't been activated in your thread. You'll have comctl v5.8.

 

You need to activate the comctl v6 manifest whenever your DLL is called and deactivate whenever it returns. Every function should activate on entry, deactivate on exit. 

 

I do this in my Excel com add in. 

Oww, that sounds like a pain.   But I think it should be possible to just pack a manifest alongside an existing application, without embedding it and damaging the digital signature?

9 minutes ago, Lajos Juhász said:

You mean this reference at https://docwiki.embarcadero.com/Libraries/Sydney/en/Vcl.Controls.TImageList:

Note: Image lists depend on Comctl32.dll. If the system does not have the latest version installed, there may be problems getting images to appear.

The problem isn't tImageList related - the DLL used tImageList in the past without problems or manifest requirements until I replaced it with tImageCollection & tVirtualImageList.

Also, the operating system is Windows 10, so comctl32 on the system is most certainly the current version.  By the way, with a properly manifested application, the new icons display correctly even on Windows XP which is vintage so I don't think it's a matter of an outdated comctl32.

( edit: I compiled the test application under Delphi 11 fixpack 1 with {$SETPEOSVERSION 5.1} {$SETPESUBSYSVERSION 5.1} to make it work on XP).

Hello all,

I am using tImageCollection and tVirtualImageList inside a COM DLL to display some images on buttons etc.  This COM DLL is an update to an existing version - the calling processes are existing programs, many of which were compiled with older Delphi versions.

I'm observing a very strange phenomenon: the images on the buttons in the DLL are not displayed if the calling executable does not have a manifest.  They are only displayed if the calling executable has a manifest. I find no reference in the Delphi documentation that tImageCollection has manifest requirements.

Can anyone shed some light on this?

My reason for asking: I cannot update the existing legacy applications with a new manifest - they are digitally signed and inserting a new manifest would break the signature.. 

17 minutes ago, Uwe Raabe said:

It is also possible that VMware will have a decent solution then.

Sure. Until that time, I'll just stick with Windows 10 in the VM. 

4 minutes ago, emileverh said:

I agree. DPI awareness in Delphi 11 is a mess!!  People who are telling; you have to develop in 96dpi mode do not own a high-end PC with a high resolution screen. The forms are incredible small in that way, it's impossible to design a form. And frames are the worst part....

One simple workaround is to run Delphi inside a VMWare VM and to configure that VM so, that its resolution is 1920x1080 and "stretched".  That way Delphi will run at a resolution of 2K even though the monitor really has a much higher resolution.

As for DPI awareness in compiled Delphi applications themselves, I have a whole bunch of workarounds to make things work better. The key for me was to inherit every TForm from a common ancestor and to override some virtual methods in that ancestor  (DoBeforeMonitorDPIChanged, DoAfterMonitorDPIChanged, Loaded, Docreate and some more ...)  to fix the most egregious bugs.  That way any form derived from that common ancestor behaves much better.

1 hour ago, Uwe Raabe said:

VMware has a workaround for ignoring the TPM requirement mentioned in Installing Windows 11 as a guest OS on VMware Workstation Pro/Player and Fusion

 

That workaround is well known, but it'll probably cease working when the first updates of Windows 11 appear. In that case one would be stuck with a possibly buggy initial version.

1 hour ago, Sherlock said:

Well cancel Windows 11 then. No need for it anyway. Only for testing. Some folks still use WinXP, being stuck on Win10 till MS comes to their senses seems not that long.

Some things (like Per-Monitor DPI-awareness V2) are really awkward to test through Remote Debugging.  Delphi 11 still has tons of issues regarding DPI Awareness, for which I had to devise workarounds until Embarcadero hopefully gets it right. I expect some improvements to this feature in Windows 11 and it would be really nice to be able to debug it natively rather than remotely.

1 hour ago, David Schwartz said:

Switch to VirtualBox perhaps?

I have no desire to switch to a different virtualization product. My appreciation of  VMWare far exceeds any desire for Windows 11.

1 minute ago, Attila Kovacs said:

If not, you should not use that product.

That's not an option.  VMWare workstation is essential to me, also because of compatibility with ESXI.  (I don't know if other virtualizers that use "passthrough" TPM's don't have the same problem, because in that case the TPM also dies if the host breaks)

1 hour ago, Attila Kovacs said:

You know that for this reason a recovery key/image/etc... should be generated? 

Will that work on a new hardware? I mean, will VMWare Workstation boot a recent backup, if I exchange my notebook for a new one?

14 minutes ago, Attila Kovacs said:

With your logic not only the VM but an encrypted HDD would not be recoverable anymore.

A virtual HDD encrypted by VMWare would not be recoverable anymore indeed.

[edit]

I make weekly backups of my VM's on an external HDD. If they were cryptographically tied to my notebook's hardware, they would become worthless if my notebook broke.

Hello all,

this question isn't strictly Delphi related but rather Windows 11 / VMWare Workstation related.

I develop under Windows 10 X64 in a VMWare virtual machine. I'd like to migrate this VM to Windows 11 but there are a few things that currently make this unfeasible IMHO:

- before adding a virtual TPM module, VMWare insists on encrypting all virtual hard drives (*.vmdk files) of the VM.

- The encryption key contains information of the host machine. The drives will only decrypt on the same host machine.

- So if my notebook dies, I'm basically scr##ed because the VM won't run anywhere else.

That's totally unacceptible to me. The whole purpose of virtualization is having virtual hardware so the VM's are independent of the host hardware and its life span. A backup of a VM shouldn't be worthless if my hardware breaks!  I currently have VM's that were created on at least 3 different machines and they still run fine, thanks to a vmx entry uuid.action= "keep" that tells VMWare to maintain the machine identity even if the VM is moved to a different machine.

So... What gives? Is there a viable workaround for this problem? 

I know about the undocumented managedvm.autoAddVTPM="software" vmx entry but let me warn you, that has dire side effects: instead of encrypting the vmdk files as a whole it will just encrypt the header area of the vmdk files. That is even worse because you can't undo it - the decryption password isn't revealed. And it's not documented if this header encryption is machine dependent or not.

27 minutes ago, Uwe Raabe said:

The docs are pretty clear about it (Message Methods😞

 

Ah, I've overlooked that! Thanks! 

One of the reasons I asked is because many of these message handlers in Vcl.Forms are declared  private.  But apparently, the keyword "private" is meaningless for message methods if they're resolved by number.

Hello all,

I have a question regarding dynamic methods in Delphi that handle Windows messages. The documentation is not clear about this.  Suppose I declare a Windows message handler in my form like 

 procedure WMNCCreate (var Message: TWMNCCreate); message WM_NCCREATE;

with a trivial implementation like

procedure WMNCCreate(var Message: TWMNCCreate); 
begin
  inherited;
end;

how is the inherited() call resolved by Delphi? Is it resolved by method name or by message number?

In other words, does inherited() call an ancestor's method having the name WMNCCreate,  or does it call any method that handles message number WM_NCCreate regardless of the method's name ?

4 hours ago, Fr0sT.Brutal said:

Just a small change:

unit DMSomething;

uses ..., NoDPIDataModule; // add this

type
  TDataModule = NoDPIDataModule.TDataModule; // and this

  TDMSomething = class(TDataModule)
  ...

 

Would it not be necessary to change the DFM file too (change "object" into "inherited") because of this inheritance?

5 hours ago, baoquan.zuo said:

type
  {$I jedi.inc}
  {$IFDEF DELPHI28_UP}
    {$DEFINE HasPixelsPerInch}
  {$ENDIF}

  TBaseDataModule = class(TDataModule)
  {$IFNDEF HasPixelsPerInch}
  protected
    // Ignore PixelsPerInch property in TFrame introduced since Delphi 11
    procedure DefineProperties(Filer: TFiler); override;
    procedure IgnorePixelsPerInch(Reader: TReader);
  {$ENDIF}
  end;

{$IFNDEF HasPixelsPerInch}
procedure TBaseDataModule.DefineProperties(Filer: TFiler);
begin
  inherited DefineProperties(Filer);
  Filer.DefineProperty('PixelsPerInch', IgnorePixelsPerInch, nil, False);
end;

procedure TBaseDataModule.IgnorePixelsPerInch(Reader: TReader);
begin
  Reader.ReadInteger;
end;
{$ENDIF}

I created a base module to solve this kind of issue 

I like the idea, but it would require changing existing projects. Existing datamodules, services and frames would need to inherit from new classes.  Maybe it would be more elegant to write a patching unit for older Delphi versions that hooks into the dfm reader and ignores PixelsPerInch. 

16 hours ago, Uwe Raabe said:

They are visual in the designer and the designer has to know the resolution the datamodule has been designed last.

 

I know this is annoying and even error prone. That's why I made a suggestion to store all dfm with an implicite PixelsPerInch value of 96 and scale only for designing: Option to design in Screen PPI but save in 96 PPI

That may cause the non-visual components on the datamodule moving out of sight in the designer when the datamodule is opened about 2-3 times.

AFAIK there is no property "scaled" in tService and tDatamodule, so why would the designer need to know PixelsPerInch if it's not supposed to do any scaling? There's "Width" and "Height" so it can still create the window big enough to display the placed components.

As a workaround, I've written a command line application that detects if a DFM is tdatamodule or a tservice and if so, removes the "pixelsperinch" property. Maybe I should do the same for tFrame because I intend to always use 96 dpi in design mode. The tool is now integrated in my Finalbuilder build scripts and so far it looks promising.  If it is error-free, I may use it inside a pre-commit hook in SVN as well.

Hello all,

it is *extremely* annoying that Delphi 11 writes a property "PixelsPerInch" into dfm files of type tDatamodule and tService.  Such objects are totally non-visual so what the heck ?
This property cause runtime errors when such projects are compiled with Delphi 10 or older.  I now have to manually strip it from each and every data module using Notepad!

Hello all,

I'm having some trouble debugging DLL's in Delphi 11, trouble which I did not have before in Delphi 10.4.   
My DLL is compiled in debug mode and has remote debugging symbols.

If I specify the host executable (Run-> Parameters -> Debugger -> Host application) and execute the process, breakpoints will not fire in my DLL.

But....  if I start the application manually and tell the debugger to attach to the process, breakpoints will fire in the DLL without any problems.

This workaround works, but it is super uncomfortable and slows me down.  Any idea how I can get the debugging situation back to normal?