Delphi 13 FMX applications not responding to mouse clicks on Win10 multimonitor

[Lachlan Gemmell 36]

I have a pretty unique multimonitor screen arrangement on my dev system

 

 

and FMX applications compiled with Delphi 13 don't respond to mouse movements or clicks if the window is in the top third of monitor 3 (which is my primary monitor).

 

Specifically the client area of the FMX window doesn't respond to mouse movements or clicks while it is within that region. The non-client area responds fine allowing you to move, maximise, close the window as you would normally.

 

Interestingly the Delphi 13 IDE FMX designer suffers the same problem if I place it on monitor 3. Anything in the top third of that monitor I cannot select.

 

I've verified it using both my application and the standard demo found at Samples\Object Pascal\Multi-Device Samples\User Interface\ControlsDesktop\ControlsDemo.dproj

 

If I compile my FMX app or that FMX demo using Delphi 12.3 it works on every monitor no problem. VCL applications also don't have any issue either.

 

I'm guessing for most people you won't have an issue but if there's anyone else out there with a wacky screen arrangement you may be seeing something similar.

 

If you are please post your multimonitor arrangement here. It would be nice to be able to report the issue with a simpler multimonitor arrangement than mine to increase the chances of Embarcadero being able to reproduce the issue.

[Lachlan Gemmell 36]

I've discovered the issue was introduced by a rewrite of the FMX.Platform.Screen.Win.TDpPxConverter.RebuildTable in Delphi 13. That method constructs a two dimensional array TDpPxConverter.FTable of TDpPxConvertor.TCell records representing different regions of your entire display area both onscreen and off. 

 

This rewritten method however appears to leave some of those TCell record fields without a value (probably only for those with over the top multimonitor configurations like mine). Specifically it's the TDpPxConvertor.TCell.LocationDP field that appears to contain rubbish in some of the records of that TDpPxConverter.FTable two dimensional array.

 

I'll report the issue to Embarcadero [RSS-4146] but if anyone else encounters the issue and needs a workaround let me know. My workaround is a very rough hack specific to my screen configuration so it's not worth the effort explaining it here unless others are having the same problem.

Edited Thursday at 04:21 AM by Lachlan Gemmell

[eivindbakkestuen 57]

On 9/17/2025 at 7:26 PM, Lachlan Gemmell said:

I have a pretty unique multimonitor screen arrangement on my dev system

Now, there's a prime candidate for "a picture, or it never happened"!!! LOL

[Brandon Staggs 394]

On 9/17/2025 at 8:36 PM, Lachlan Gemmell said:

I've discovered the issue was introduced by a rewrite of the FMX.Platform.Screen.Win.TDpPxConverter.RebuildTable in Delphi 13. That method constructs a two dimensional array TDpPxConverter.FTable of TDpPxConvertor.TCell records representing different regions of your entire display area both onscreen and off. 

 

This rewritten method however appears to leave some of those TCell record fields without a value (probably only for those with over the top multimonitor configurations like mine). Specifically it's the TDpPxConvertor.TCell.LocationDP field that appears to contain rubbish in some of the records of that TDpPxConverter.FTable two dimensional array.

 

I'll report the issue to Embarcadero [RSS-4146] but if anyone else encounters the issue and needs a workaround let me know. My workaround is a very rough hack specific to my screen configuration so it's not worth the effort explaining it here unless others are having the same problem.

That RSS is not visible to me for some reason.

 

What was your workaround? We're finding that some unusual configurations fail PxToDP -> DpToPx on version 12.3. Looking at the code it just doesn't seem like it can work properly in all cases.

[Lachlan Gemmell 36]

@Brandon Staggs the RSS is correct but its state is "Ready for Validation" which perhaps means others can't see it yet. I shared it with you personally via JIRA though so perhaps you will be able to see it now.

 

Like I said, my workaround is pretty rough and very specific to my system but easy for you to adapt if you have Delphi installed on the system to debug the method and discover the correct values to substitute.

 

Inside TDpPxConverter.DefineCellByDP find the if statement inside the nested for loops and make the following modification to a copy of FMX.Platform.Screen.Win.pas that's added to your project.

      if InRange(APoint.X, Cell.LocationDP.X, Cell.LocationDP.X + Cell.SizeDP.Width) and
         InRange(APoint.Y, Cell.LocationDP.Y, Cell.LocationDP.Y + Cell.SizeDP.Height) then
      begin
        (* WORKAROUND - AColumn and ARow are first correctly set to 0 and 0, 
        but then later incorrectly overwritten with 6 and 2. Abort before that happens *)
        if (Col = 6) and (Row = 2) and (AColumn = 0) and (ARow = 0) then
          Break;
        (* WORKAROUND ENDS *)
        AColumn := Col;
        ARow := Row;
        Break;
      end;

What do you see in Delphi 13? Did the new implementation fix it for you?