Vincent Parrett

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.

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.

That might be so, but you probably have a bunch of covid in the community too.. I'll stay down under where it's under control at the moment 😉

Bugger, sorry to hear that, hope you are well on the mend! We've been extremely fortunate here and haven't had a community transmission case for quite some time (at least where I live). Being an island and closing the borders helped immensely. The vaccine rollout is very slow, I can't get it till end of May last I heard (lack of supply).

Using precompiled dcu's is common sense really.. imagine if you had to build the rtl/vcl/fmx every time you build your application⏲️ In the dpm package manager I'm, working on, it compiles the packages/library when the library is installed (assuming its designed to do that) - so the first time you install the package it takes a bit longer, but then builds are a lot faster.

As the old saying goes, used regex to solve a problem? now you have two problems! 🤣 That said, I use regex extensively both in Delphi (I wrote the original System.RegularExpressions code) and .Net (keep it simple, and it's not for parsing html!) - but using it to find problems with my code? ah nope, for that I use Eyeballs 1.0 and static analysis tools like FixInsight and Pascal Analyzer (yes I know they have their limitations). Plus I guess I have learned a few things over the years that I apply in new code I write. As for the old code, well refactoring is a work in progress. Yesterday I rewrote a lexer/parser framework I initially wrote 10 years ago due to performance issues, and that issue was identified through profiling (see the thread on vtune). Switching to records took the memory manager from being a big % to insignificant (ie no longer shows up in the profiler). I thought I might get something like a 10% improvement, but was pleasantly surprised to see a 30% improvement! Those sort of gains don't come often in a mature code base.

I just had my first big win with VTune 😃 I was looking into improving the performance of loading projects in FinalBuilder 9 (in dev) - we have some customers with huge projects that were taking a while to load. Profiling with VTune showed that most of the time was spent in the project lexer/parser - the lexer created class based tokens (and some other associated classes) and a lot of time was spent in the lexer and the memory manager. So 3 hours later, the code has been converted to use records rather than classes - the unit tests all pass (I only had to comment out all the Assert.IsNotNull(token); calls) and the application runs normally (still need to code review to make sure I didn't break things). The result is around a 30% improvement with that change alone! That's just me counting out loud as the project loads 😉 - I'll do more formal timing/testing tomorrow. I also just compared to FinalBuilder 8 and the total improvement is more like 60% - I'll put that down to some manual code review looking for possible hotspots over the last week, and also to switching from the rtl generic collections to using spring4d everywhere! Time for some sleep, but looking forward to more VTuning tomorrow. Thanks @Anders Melander again for this amazing bit of work!