Vincent Parrett

This is a bad idea, should only ever be enabled while developing the package. Having the IDE rebuild packages which will be loaded into the ide isn't a good idea - I touched on rebuild as needed in this post https://www.finalbuilder.com/resources/blogs/advice-for-delphi-library-authors What do you have in your dpk? Don't try ifdeffing in there (the IDE doesn't handle it well), better to create two separate package projects and explicitly add fmx or vcl to the requires clause.

I think you should evaluate both and decide which suits your needs best. I've mostly used madexcept but when I have used Eurekalog it's worked fine.

So far so good. I turned LSP back on, was able to do a full build (100+ projects in the group) - then debug the main project, exit, change some code, compile and debug again. The IDE is using a lot of memory though. Code navigation between projects is still broken for LSP (when only referencing dcp's) - so back to classic code insight it is.

I haven't tried this, but if you have the map file, you could use map2pdb and then use windbg to figure out where the exception occurred. As @David Heffernan mentioned, madEcept or Eurekalog are the way to go - they are invaluable for getting usable stack traces, I've fixed countless bugs in my code thanks to madExcept.

That's exactly what I am doing, since the packages are plugins that the user can choose not to load. It's no where near as simple as you make out. And really, my code and application architecture is not the issue here.

Are you volunteering to rework my application architecture if it's that easy - I have 100+ package projects in a project group, a few dll's and 4 exe's (around 4M lines of code) and I see these errors all the time. I cannot use LSP at all because of this, but even with it turned off the IDE and the compiler are unstable. I can't afford to spend months refactoring my code in the hope that the IDE or compiler might then just behave correctly 🙄

So today I took a copy of the TFormStyleHook (a bit of work due to use of protected methods on TCustomForm) and registered for my form class and started adding some outputdebug strings. (BTW, it's staggering how much code there is (with many corner cases) in the stylehook! This is what happens when restoring after minimizing on monitor 0 (the non primary monitor) TVSoftFormStyleHook.WMWindowPosChanging x : 0 y 0 w : 0 h : 0 flags[ SWP_NOMOVE + SWP_NOSIZE ] Form Bounds: Left: 3803 Top: 499 Width: 1302 Height: 675 TVSoftFormStyleHook.WMWindowPosChanging x : 2549 y -11 w : 3862 h : 2182 flags[ SWP_NOCOPYBITS + SWP_FRAMECHANGED ] Form Bounds: Left: 3803 Top: 499 Width: 1302 Height: 675 TVSoftFormStyleHook.WMWindowPosChanging x : 0 y 0 w : 0 h : 0 flags[ SWP_FRAMECHANGED + SWP_NOACTIVATE + SWP_NOZORDER + SWP_NOMOVE + SWP_NOSIZE ] Form Bounds: Left: 3803 Top: 499 Width: 1302 Height: 675 TVSoftFormStyleHook.WMWindowPosChanging : Applying FRestoringContraints TVSoftFormStyleHook.WMWindowPosChanging x : 0 y 0 w : 1302 h : 675 flags[ SWP_NOACTIVATE + SWP_NOZORDER + SWP_NOMOVE ] Form Bounds: Left: 3803 Top: 499 Width: 1302 Height: 675 SetBounds: Left: -32000 Top: -32000 Width: 1302 Height: 675 TVSoftFormStyleHook.WMWindowPosChanging x : -29440 y -32000 w : 0 h : 0 flags[ SWP_NOACTIVATE + SWP_NOZORDER + SWP_NOSIZE ] Form Bounds: Left: -32000 Top: -32000 Width: 1302 Height: 675 FormAfterMonitorDpiChanged : OldDpi : 144 NewDPI : 96 TVSoftFormStyleHook.WMWindowPosChanging x : 0 y 0 w : 0 h : 0 flags[ SWP_FRAMECHANGED + SWP_NOACTIVATE + SWP_NOZORDER + SWP_NOMOVE + SWP_NOSIZE ] Form Bounds: Left: -29440 Top: -32000 Width: 1302 Height: 675 TVSoftFormStyleHook.WMWindowPosChanging x : 0 y 0 w : 0 h : 0 flags[ SWP_NOMOVE + SWP_NOSIZE ] Form Bounds: Left: 2552 Top: -8 Width: 3856 Height: 2116 As you can see it is called at least once with co-ordinates that are on the other monitor (monitor 1) - which is why the errant WM_DPICHANGED is fired!! I tried to decode the flags as well I commented out this line in TVSoftFormStyleHook.WMWindowPosChanging and that seems to solve it, however we then no longer have any constraints. Form.Constraints := FRestoringConstraints; So while I can see what is happening, I haven't quite figured out why - it seems like the constraints are somehow lost when minimizing, however resetting them in WMWindowPosChanging is causing windows to believe the window has changed monitors. What a mess.

Last one before I give up on this for today. It seems to be caused by TFormStyleHook.WMWindowPosChanging calling Form.Constraints := FRestoringConstraints; - this causes a flurry of calls to SetBounds - proving difficult to debug, but at some point the incorrect bounds are set and windows then fires off the dpi changed message -while debugging I saw the window jump and then the dpi change message fired.

I'm getting nowhere with this - something is causing windows to send WM_DPICHANGED when restoring the window - according to the documentation for WM_DPICHANGED the message is sent when The window is moved to a new monitor that has a different DPI. The DPI of the monitor hosting the window changes. We are definitely not changing the dpi of any monitors, so that suggests that windows thinks the window has changed monitors. I've been looking though the vcl source but cannot see where that is happening. Since this only happens with vcl themes enabled I think it's safe to say this is probably not a windows bug. @Carlo Barazzetta did you report this yet? If so post the number here so we can vote for it. Hopefully we can find a workaround for this because I guarantee I will have customers reporting this as an issue with my software otherwise.

More info If I change my debug output to do this monitor := Screen.MonitorFromPoint(Self.BoundsRect.CenterPoint);// MonitorFromWindow(Self.Handle); Memo1.Lines.Add('Current Monitor : ' + IntToStr(monitor.MonitorNum)); It always give the correct monitor. Current Monitor : 1 Windows Bounds (Top,Left,Bottom,Right) : -8,-8,1408,2568 Current Monitor : 0 Windows Bounds (Top,Left,Bottom,Right) : -11,2549,2111,6411 Those top/left values on monitor 0 looked odd, so I turned off themes Current Monitor : 1 Windows Bounds (Top,Left,Bottom,Right) : -8,-8,1408,2568 Current Monitor : 0 Windows Bounds (Top,Left,Bottom,Right) : -11,2549,2111,6411 So that's not it, some googling found this is explained here - https://devblogs.microsoft.com/oldnewthing/20120326-00/?p=8003 So I'm no closer to figuring this out.

So I added some debugging info to see what is going on, iterating the screen.monitors collection procedure TForm3.ListMonitors; var i : integer; monitor : TMonitor; begin Memo1.Lines.Clear; for i := 0 to Screen.MonitorCount -1 do begin monitor := Screen.Monitors[i]; Memo1.Lines.Add('Monitor idx : ' + IntTostr(i)); Memo1.Lines.Add('Monitor num : ' + IntTostr(monitor.MonitorNum)); Memo1.Lines.Add('Monitor primary : ' + BoolToStr(monitor.Primary,true)); Memo1.Lines.Add('Monitor ppi : ' + IntToStr(monitor.PixelsPerInch)); Memo1.Lines.Add('Monitor size (Top,Left,Width,Height) : ' + IntToStr(monitor.Top) + ',' + IntToStr(monitor.Left) + ',' + IntToStr(monitor.Width) + ',' + IntToStr(monitor.Height)); end; Memo1.Lines.Add(''); monitor := Screen.MonitorFromWindow(Self.Handle); Memo1.Lines.Add('Current Monitor : ' + IntToStr(monitor.MonitorNum)); end; My primary monitor is 1 (96dpi) which is to the left of 0 (144 dpi) - this is after moving the window to monitor 0 (the one on the right). Monitor idx : 0 Monitor num : 0 Monitor primary : False Monitor ppi : 144 Monitor size (Top,Left,Width,Height) : 0,2560,3840,2160 Monitor idx : 1 Monitor num : 1 Monitor primary : True Monitor ppi : 96 Monitor size (Top,Left,Width,Height) : 0,0,2560,1440 Current Monitor : 0 After minimizing and restoring (so still on monitor 0) Monitor idx : 0 Monitor num : 0 Monitor primary : False Monitor ppi : 144 Monitor size (Top,Left,Width,Height) : 0,2560,3840,2160 Monitor idx : 1 Monitor num : 1 Monitor primary : True Monitor ppi : 96 Monitor size (Top,Left,Width,Height) : 0,0,2560,1440 Current Monitor : 1 Clearly Screen.MonitorFromHandle is returning the incorrect monitor - I suspect this is the cause of the issues I'm seeing with menus too. Looking at the code behind MonitorFromHandle I can't see what the problem is, I suspect this may be a windows bug?

Ok I can now reproduce this here after reading the above, when I tried it before I didn't move it to monitor 1 (2 is my primary). Even worse, when minimizing it the second or third time, it jumps over to the other monitors task bar, but restores to the correct monitor. Something is very broken with monitor detection. I'm seeing a similar issue with menus and vcl styles when moving between monitors - depending on which monitor a menu is first used on it will either be displayed too small or too large - it seems like it's finding the wrong monitor to get the dpi. I've been trying to debug this for days but it's very difficult to debug since that seems to impact on the behaviour.

I couldn't reproduce this here, although my second monitor shows as 144 dpi (4k at 150%).

Use the web installer, you can then choose which parts to install.

With @Stefan Glienke changes merged it's blazingly fast👍. I added a postbuild event to every project in my project group (131 projects) and barely notice it running now! This is what I have for the postbuild event %MAP2PDB% $(OUTPUTDIR)\$(OUTPUTNAME).map -bind:$(OUTPUTDIR)\$(OUTPUTFILENAME) Note that I did needed the outputfilename part for the bind option as it only looks for exe (so for bpl, dll you need it). I created an environment variable for the path to map2pdb to avoid hard coding the path in my dproj files. Sadly if you use libsuffix anywhere you need to manually add that in to the map file arg as $(OUTPUTNAME) doesn't include it, and there isn't a macro for it.