ULIK

Well, I hope, that next release will improve this ...

Well, I'm not sure if anyone on Embarcadero has really tested the IDE running on a system with multiple monitors and different DPI scaling, especially, if the primary monitor has a different scaling then 96 DPI. There are so many problems (fonts do not scale or scale too large, IDE toolbars getting too large or moving their position, ...) 

It can be a hard job (I'm currently trying to make our own application to be per monitor aware and I'm still not finished after 4 weeks) but if they promote the IDE to be support High DPI, it should work at least a little bit better.

I doubt that there is an library available for Delphi that will solve your problem out of the box. But as you already found, you can use Linear Programming for this but you still have to adjust the evaluation method for your own needs.

Here are some libraries I found on the fly:

https://www.optimalon.com/linear_programming_library.htm

https://www.alglib.net/linear-programming/

I'm not sure, if this is related to new MMX15.1 but I just noted, that the hint window for methods on explorer window truncates the hint:

Just installed 15.1.1: loading time on IDE startup is fast again! Thank you very much for fixing this!

I'm sorry, I had to give up on MMX 15.1. Those heavy scans while starting the IDE makes it too hard to work with. I'm not sure about the cache as starting the IDE again the next day I noticed again such heavy loads as well as on further restarts of IDE. Unfortunately the current project I'm working on depends on a lot of external component packages as well as requires a lot of restarts of IDE over the day.

So for now I back on 15.0.49 and everything is fine again.

Thank you for explaining! As the packages do not change that often, I see no problem for me.

Hello Uwe,

thank you for that major update. I noticed one thing where I do not know, if it is related to the new MMX build or something else:

- today IDE (11.1)  was not yet started

- I installed the update to MMX 15.1

- Then started the IDE

- Now I noticed a massive slow down when loading all the IDE packages (especially DevExpress) and task manager shows a very heavy load on BDS.exe

- It completed after some time (2-3 minutes)

- I closed the IDE

- a new start now loads much faster (like it was the days before)

It is the first time that I have seen this so could this be related to new build (some preprocessing maybe?)

Have you already tried it with a combination of splines? They would touch the vertices.

Hmm, I can't reproduce this here for 'Save All'. Please try it on a fresh VCL or FMX application.

This bug was already there at least on 11.1: https://quality.embarcadero.com/browse/RSP-38001

Davide,

it's just a vague guess: you use a dark color scheme on IDE. Do you see the same problems also when using the light default scheme?

Done: https://quality.embarcadero.com/browse/RSP-37770

Hi,

can someone confirm this behavior: When placing the IDE object inspector on a special location tabbed with project, IDE font changes on a dual monitor system with different DPI settings.

Prerequisites:

- main monitor using 96 DPI  (2560 x 1440)

- secondary monitor using 144 DPI (3840 x 2160)

- screen extended on both screens

- standard desktop is set to 'Standard Layout'

( - no other IDE extensions like MMX or GEXperts loaded)

- Delphi IDE XE 11.1 (DPI aware) running on main monitor : maximized window

Steps to reproduce:

- load a new VCL app

- drag the object inspector to 'Project' window and place it left beside the 'Project' tab (see IDE_step_1)

- save this as desktop 'Standard Layout_1'

- make this new layout the new standard layout

- close the project

- again create a new VCL app

Now see, how the font has changed:

Using this new standard layout I can reproduce the font change every time by:

- start Delphi IDE

- create new project (or load existing one)

- close this project (not the IDE)

- again load the project

kind regards,

Ulrich

After installing Update 11.1 I can no longer reproduce this problem. 👍

Hi,

I'm not entirely sure that this is really related to MMX but using some MMX Windows I'm able to reproduce:

Prerequisites:

* place the two desktop definition files from attachment ( Test.zip ) on location for desktop definitions 

* make sure you have a secondary monitor using a different DPI scaling ( 150%)  right beside your primary monitor  (100%) !

* Delphi XE11 starts on primary monitor

Steps to reproduce:

* start IDE

* select desktop layout 'MMX (No GX)'  and watch bottom window 'Messages'

* select desktop layout 'MMX Debug (No GX)'

* again select layout 'MMX (No GX)' and watch bottom window 'Messages': now font size has changed!

  vs.

As far as I can tell this happens only when I have the secondary monitor available using a different DPI. The problem gets more worse as some other IDE windows also change their font size and column positions (inspector, GExperts Search result window etc. )

Is someone able to reproduce this behavior? As said, I'm not sure if this is really related to MMX (installed experts: MMX, GEXperts)

kind regards,

Ulrich

Hi Uwe,

just a very small point: when changing the color theme on DX11 from light to dark, MMX CodeExplorer window does not fully handle this:

start IDE, load a project and make CodeExplorer window visible. Then change the color theme of IDE:

I have to restart the IDE to make the upper part dark as well. Nothing important, just noticed it when playing around with new DX11.

kind regards,

Ulrich

Yeah! That's an extension I really like! 👍

Hi,

when I print an image using GDI+ DrawImage method on a high DPI system (192 DPI), the result differs from what printer is used. Next is my test code:

procedure TForm1.Button1Click(Sender: TObject);
var
  DC: HDC;
  gpGraphics: TGPGraphics;
  gpImage: TGPBitmap;
  gpPen: TGPPen;
  nLogPixUI: Integer;
  nLogPx: Integer;
  png: TpngImage;
  rDest: TGPRectF;
  rectImage: TRect;
  rectImage72: TRect;
begin
  memo1.Clear;

  // Just to get some information on the image
  png := TPngImage.Create;
  try
    png.LoadFromFile('image.png');

    memo1.Lines.Add(Format('PNG.Width: %d', [png.Width]));
    memo1.Lines.Add(Format('PNG.Height: %d', [png.Height]));
    memo1.Lines.Add(Format('PNG.Res: %d, %d', [png.PixelInformation.PPUnitX, png.PixelInformation.PPUnitY]));
  finally
    png.Free;
  end;



  if PrintDialog1.Execute(Handle) then
  begin
    Printer.BeginDoc;
    try

      gpGraphics := TGPGraphics.Create(Printer.Canvas.Handle);
      try
        // let's use pixel
        gpGraphics.SetPageUnit(UnitPixel);

        // get device DPI
        DC := gpGraphics.GetHDC;
        try
          nLogPx := GetDeviceCaps(DC, LOGPIXELSX);
          memo1.Lines.Add(Format('Log. Pixel Device: %d', [nLogPx]))
        finally
          gpGraphics.ReleaseHDC(DC);
        end;

        // and create an image rectangle based on some MS Ink coordinates
        nLogPixUI := Screen.MonitorFromWindow(Self.Handle).PixelsPerInch;
        memo1.Lines.Add(Format('Log. Pixel Screen: %d', [nLogPixUI]));

        // create the image rectangle, based on a 90x90 pixel rectangle  (just for test)
        rectImage.Create(
          MulDiv(10, nLogPx, nLogPixUI),
          MulDiv(10, nLogPx, nLogPixUI),
          MulDiv(100, nLogPx, nLogPixUI),
          MulDiv(100, nLogPx, nLogPixUI)
        );

        // center coordinates system on image midpoint
        gpGraphics.TranslateTransform(rectImage.CenterPoint.X, rectImage.CenterPoint.y);

        gpPen := TGPPen.Create(ColorRefToARGB(ColorToRGB(clRed)), 1);
        try
          // create a red rectangle around the image
          gpGraphics.DrawRectangle(gpPen, - rectIMage.Width/2, - rectImage.Height/2, rectImage.Width, rectImage.Height);

          // load the image
          gpImage := TGPBitmap.Create('image.png', False);
          try
            memo1.Lines.Add(Format('Img.Width: %d', [gpImage.GetWidth]));
            memo1.Lines.Add(Format('Img.Height: %d', [gpImage.GetHeight]));
            memo1.Lines.Add(Format('Img.Res: %f, %f', [gpImage.GetHorizontalResolution, gpImage.GetVerticalResolution]));

            // create the destination rectangle for printing based on rectImage
            rDest.X := -rectIMage.Width/2;
            rDest.Y := -rectIMage.Height/2;
            rDEst.Width := rectIMage.Width;
            rDest.Height := rectImage.Height;

            gpGraphics.SetInterpolationMode(InterpolationModeHighQualityBicubic);
            gpGraphics.SetSmoothingMode(SmoothingModeHighQuality);
            gpGraphics.DrawImage(gpImage, rDest, 0, 0, gpImage.GetWidth, gpImage.GetHeight, UnitPixel);

          finally
            gpImage.Free;
          end;
        finally
          gpPen.Free;
        end;
      finally
        gpGraphics.Free;
      end;


    finally
      Printer.EndDoc;
    end;
  end;
end;

When I run this code against the attached image (see below) on a 96 DPI desktop system, everything is fine when printing on Microsoft PrintToPDF as well as any other installed printer:

Next I run the same code on a SurfacePro 7 with 192 DPI.  Now the result differs from used printer:  HP Universal PS as well as SnagIt produce the expected output:

But Microsoft Print to PDF, OneNote for Windows 10 and a HP Laserjet 400 MFP M425dw (607BA1) printer creates a wrong output: rectangle size is fine but content not.

So the question is: why produces the output on different printers different outputs? It looks like the wrong output includes some scaling between 96 and 192 DPI but DrawImage should be independent of it, when setting source, destination explicitly. Especially why this is printer dependent?

Any ideas, what causes this problem?

Thanks,

Ulrich

forgot to mention: Delphi XE 10.2 Tokyo

used image for printing:

Thank you! The workaround is working 🙂

Hi!

can anyone confirm this bug (?): Delphi 10.2.3, MMX 15.0.11 Build 2371

- create a new unit

- type the following class declaration:

 TMyClass = class(TObject)
 private
   FTest: Integer;
 public
   property Test: integer read FTest write FTEst;
 end;

- now select the property on MMX code explorer and hit Ctrl+E to edit it

Here this results always in this message:

kind regards,

Ulrich

There is a very small glitch on 'Add Event' dialog: the header caption of first tab displays the caption of the dialog instead just 'Event' as the other Add ... dialogs would indicate.

I can't remember if this is related to MMX 15 or has always been there. 

Just installed this latest version: now opening the new property dialog is fast: just a second instead of more then 10 seconds!

Thank you very much for your fine work!

Thanks for explaining!

No sure that I understand you right: adding a new property to a class is not so much uncommon for me (and that's what I did: selecting the new TForm1 object and added a property. Or do you mean that there is MMX internal code doing some strange things?