Vincent Parrett

Confirmed - this only happens when Classic Code Insight is enabled.

That could be it, I have LSP turned off due to issues, so perhaps it's Classic insight vs LSP that determines whether it occurs?

100% reproducible with a new VCL project, no IDE plugins installed.

When I saw this post it triggered something that has been bugging me for a while, which is how long it takes to run after I have already compiled - so I watched the exe date time and observed the change - I don't use MMX but thought perhaps it was another (or any) plugin - so I removed them (and confirmed they were gone) before testing again - it's 100% reproducible with my main project - I didn't test with a new project though.

I'm seeing this issue here and I do not have mmx installed - I did a full build, waited 1 minute and then hit Run - the exe is most definitely re-linked - oddly the exe size changes each time too. I did have GExperts and your Stefan's uses helper plugin - disabling them made no difference - the exe is still regenerated every time! So this looks like an IDE issue not MMX or any other plugins.

What integration would you like to see. Not making any promises here but it's much easier to get things right if we know what customers want rather than guessing 😉

Anyone know of a better way to determine the width as it would be displayed. Canvas.TextWidth is consistently giving back too a value that is around 15-20% too small. I'm using this in a custom control and have assigned the control's font to the canvas.. all to no avail. I have spent at least an hour searching for answers to this but got nowhere. I feel like I must be missing something obvious?

Solved - the font style was being changed elsewhere which was causing TextWidth to return the value for a different font style! 🤦‍♂️

This is something I'm working to improve with my package manager project. I would just say I want to install Jcl and it would work that out and install the dependencies etc in the correct order.

I'm really not a fan of installers like this either.. and especially not a fan of code that a bunch of different modes/ifdefs that change it's behaviour. I would imagine that would be a nightmare for support - having to first work out how it was installed (with the correct options) before trying to reproduce issues. Jcl/Jvcl has always been too complicated - there are some real gems in there but I tend to avoid them because if you use one unit it pulls in 50 more - delphi being delphi, not everything is optimised away. Granted it's been many years since I last looked at it.. but just looking at that installer is enough make me avoid it.

I have 12 versions of delphi on my dev machine (XE2-10.4.2) all working fine. The trick is managing your system path environment variable.. which the delphi installer still rudely prepends it's entries to.. the result of which can push the path length over 2048 which on some older systems will cause issues with windows. The trick is to not install in the default location and keep the paths as short as possible. This blog post from 2014 always gets lots of views shortly after a new delphi release - I wonder why?

It's certainly gotten better, but the generated manifest is still missing the Description and AssemblyIdentity (required as per the specs) elements.

^^^^ is the answer. There are a bunch of reasons why this is better than using the ide generated manifest file

I have seen this issue with my IDE plugin too... the problem is the IDE is not a normal VCL app when it comes to themes(it uses a custom version vcl themes).. and some controls just don't get told to repaint or that the theme has changed. I wasted a lot of time on this, but it's really an IDE problem. Delphi 10.4 is better with this than 10.3

With Vcl Themes, setting the font on the form in code works (assuming parentfont is set on all the controls). That said, I'm not sure I like Sego UI any better than Tahoma - I think Tahoma has better character spacing which makes it more readable.. especially with smaller font sizes.

Correct, it completely disables dpi scaling. Also doesn't work when using VCL Themes - seems to have zero effect. The Bitmap Style designer allows you to specify fonts for the individual elements, and I tried changing those in my themes, but again, seems to have no effect.

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.