Vincent Parrett

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.

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.