Vincent Parrett

Just a word of warning about setting ParentFont := true - I had ParentFont := true on a base form class and this completely disabled scaling on all the descendant forms! This just took me an hour of messing around to reproduce in a test project. I have no idea why ParentFont was set on that form - the project is 20yrs old and I've changed version control several times over the years so couldn't find the commit where that was set. Not sure if this is expected behaviour on forms or a bug.

You would think so, however, VCL Styles were added in XE2 and I think it wasn't until 10.3 they were added to the IDE, and even then the IDE is using custom themes (notice we can't just select any vcl theme). So they don't have a great track record of dogfooding new features.

@ewong You should not, under any circumstances, update vcl controls in a thread other than the main thread. If it's just updating a progress bar, you can do that quite simply by using PostMessage and send a user message to the form https://www.cryer.co.uk/brian/delphi/howto_send_custom_window_message.htm Use PostMessage (non blocking) rather than SendMessage (blocking). Working with threads in Delphi is harder than it needs to be. I recommend taking a look at https://github.com/gabr42/OmniThreadLibrary I also created a nice wrapper for omnithread that makes running tasks in background threads really simple : https://github.com/VSoftTechnologies/VSoft.Awaitable I've been using this in my projects for a while now (I was already using OmniThread) and it makes things so much simpler!

And I have to say, Why TF isn't something like this built into the IDE?? Nice work. It almost feels like I'm using visual studio 2012 I ended up using Shift+Ctrl+U as the shortcut so I never have to see the crappy default one - which I accidently invoked a few times now. Now for the first feature request 😉. Can you index my project search path? I just tried to us it to add Spring.Collections - but that is installed via dpm - so it's on my search path (via an msbuild property). This tool as a ton of potential... I know you don't have the time to work on it but others might, if you put it on github 😉

Huh, restarted the IDE again (third time) and now it works. Nice!

I tried, but cannot get it to show. Shift+Ctr+A just locks the IDE for about 20 seconds and then the default uses thingy (I forgot how bad it is) shows. I tried changing the shortcut but then nothing happens. Testing with 10.4.2

One last one before I give up for the day.. I added a few more outputdebugstring calls. Debug Output: TForm3.WMDpiChanged - dpi : 144 Process HighDPIDragTest.exe (52784) Debug Output: TForm3.Paint Process HighDPIDragTest.exe (52784) Debug Output: TMyPanel.AlignControls - dpi : 144 Process HighDPIDragTest.exe (52784) Debug Output: TForm3.AlignControls - dpi : 144 Process HighDPIDragTest.exe (52784) Debug Output: TForm3.Paint Process HighDPIDragTest.exe (52784) Debug Output: TMyPanel.AlignControls - dpi : 144 Process HighDPIDragTest.exe (52784) Debug Output: TForm3.WMSize- before inherited - dpi : 144 Process HighDPIDragTest.exe (52784) Debug Output: TForm3.AlignControls - dpi : 144 Process HighDPIDragTest.exe (52784) Debug Output: TForm3.WMSize - after inherited Process HighDPIDragTest.exe (52784) Debug Output: TForm3.WMSize- before inherited - dpi : 144 Process HighDPIDragTest.exe (52784) Debug Output: TForm3.AlignControls - dpi : 144 Process HighDPIDragTest.exe (52784) Debug Output: TMyPanel.AlignControls - dpi : 144 Process HighDPIDragTest.exe (52784) Debug Output: TForm3.WMSize - after inherited Process HighDPIDragTest.exe (52784) Debug Output: TForm3.AlignControls - dpi : 144 Process HighDPIDragTest.exe (52784) Debug Output: TForm3.Paint Process HighDPIDragTest.exe (52784) Debug Output: TForm3.Paint Process HighDPIDragTest.exe (52784) Debug Output: TForm3.Paint Process HighDPIDragTest.exe (52784) Debug Output: TMyPanel.Paint Process HighDPIDragTest.exe (52784) All that painting doesn't make it look any prettier 🙄 This doesn't look to be something that can be fixed with a patch or detour etc, it's going to take a rewrite of swathes of the vcl code

Ok, so I can definitively say this is a design flaw in the VCL - we are not doing anything wrong. The bug is in TCustomForm.ScaleForPPIRect the call to ScaleControlsForDpi(NewPPI) causes AlignControls to be called on the child controls and the form (depth first) - which is fine, and expected. My debug output looks like this : Debug Output: TMyPanel.AlignControls - dpi : 144 Process HighDPIDragTest.exe (3164) Debug Output: TForm3.AlignControls - dpi : 144 Process HighDPIDragTest.exe (3164) Then a few lines further down in TCustomForm.ScaleForPPIRect, it calls SetBounds and all hell breaks loose! Debug Output: TForm3.WMSize- before inherited - dpi : 144 Process HighDPIDragTest.exe (3164) Debug Output: TForm3.AlignControls - dpi : 144 Process HighDPIDragTest.exe (3164) Debug Output: TForm3.WMSize - after inherited Process HighDPIDragTest.exe (3164) Debug Output: TForm3.WMSize- before inherited - dpi : 144 Process HighDPIDragTest.exe (3164) Debug Output: TForm3.AlignControls - dpi : 144 Process HighDPIDragTest.exe (3164) Debug Output: TMyPanel.AlignControls - dpi : 144 Process HighDPIDragTest.exe (3164) Debug Output: TForm3.WMSize - after inherited Process HighDPIDragTest.exe (3164) Then it calls Realign Debug Output: TForm3.AlignControls - dpi : 144 Process HighDPIDragTest.exe (55256) So the form's AlignControls method is called 3 times, and on the panel 3 times! It should be noted that the number of times for each control depends on it or other child controls anchor or align settings (see Vcl.Controls AlignWork function), It's no wonder that things look so bad, it's because they are. Testing in 10.4.2 with VCL Styles enabled - but the code looks the same for 10.3 so this is not new.

I spent some more time looking at this and I can only describe it as a clusterf*ck. The issue is that as the application crosses over monitors, the form receives a WM_SIZE message, which calls AlignControls (which on a complex form or container control can be very slow). Cue mega rearranging of controls and repainting. Then the application received WM_DPICHANGED, which calls SetBounds, ChangeScale (which calls AlignControls) and more arranging and repainting occurs. Then add VCL Styles into the mix - for some reason with VCL Styles that WM_SIZE get's sent twice, and then the WM_DPICHANGED is sent. I have no idea why it's sent twice, but I doubt windows is doing it. I'm not even sure windows is sending the WM_SIZE at all (still investigating this). Anyway, the upshot of this is the more controls you have on a form the worse this issue will be.

I already had that in place, but in this case enabling/disabling that didn't seem to make much difference. LOL! I had forgotten about that thread (which I posted in), and it didn't come up when I was searching. FWIW, LockWindowUpdate did work for me in the WMDpiChanged handler - but setredraw seemed slightly safer. I've been trying to profile what is happening but the lack of a decent profiler is killing me! I've been using the sampling profiler, and it does show AlignControls showing up a lot (which is a known performance issue), need to investigate further.

Gotta support all those 386's that are still floating around 🙄 voted.

So you should be able to make a reproducible test case - in case there is none already. I did report this with a reproducible test case, but they knew about it long before then. https://quality.embarcadero.com/browse/RSP-32666

I got the same issue, but since Live Preview is a firemonkey/mobile thing which I don't use, I just clicked on No and moved on! My guess is it's linked to one of the Indy bpl's, and the only choice you have is a) undo what you did or b) Lose the feature. I annoys me how the IDE ships with and depends on Indy, If they use it, they should take a private copy of the library (ie rename the units) - that way we are free to update Indy without jumping through hoops.. pretty much the first thing I do after installing delphi is remove Indy (so I can use a later or known version).

Hi All Some changes with the IDE integration this week. I was unsatisfied with how the IDE plugin behaved when working with large project groups, because the Messages View doesn't show until the project group has loaded. When restoring the first time on a machine that didn't have the packages, this resulted in a potentially long period (depending on how many packages need to be installed/compiled) where no status info is available to what's going on, making it appear as though the IDE had hung. So I decided to use a window (not modal) to show the log view as the projects are loading and packages restoring. I created a custom LogMemo component to show this since I couldn't find one that suited - fortunately I already had some code to base it off (VSoft.VirtualListView). The log window will auto close after a few seconds if the restore/install/uninstall succeeds, you can configure that auto close time in the options. I also added options so you can control when the log view shows. Lastly, I added an option to not add DPM nodes to the project manager tree. On large project groups (the FinalBuilder project group has over 100 projects) it causes a long delay before the IDE is ready to use. This is because of how I had to hack into the IDE to add the nodes, the code is not at all efficient. When time permits I'll revisit this and see if I can find a better way. https://github.com/DelphiPackageManager/DPM/releases/tag/v0.1.63-alpha

Hi All As a follow up to the previous post, I have uploaded a new build : https://github.com/DelphiPackageManager/DPM/releases/tag/v0.1.64-alpha This build has a dramatic performance improvement when it comes to adding nodes to the Project Manager tree - it now has very little impact on project load times. Achieved by caching Rtti.

But, as one thing disappears, another one popped up.. the IDE just ran out of memory after chewing up 2.9GB.

Well I'm not sure what I have done, but the error seems to have gone away for the moment!

This started happening for me today too. The weird thing is, a build will fail with this error, typically towards the end of a project group, and then I can just build that project again and it will build just fine. Every day a new issue to fight, never seem to get much coding done as I spend so much time trying to work around these issues. 🤬

Don't stop now.. we're all here waiting for the exciting news (and screenshots) 😉. I've long been envious of devs who were able to use vtune (and other tools which didn't support delphi ) - this would be massive if you pull it off!

@Anders Melander have you had a look at the roslyn compiler repo, there may be some useful pdb info in there too https://github.com/dotnet/roslyn

.NET has a nice construct for this, Cancellation Tokens. I created a delphi implementation a while ago https://github.com/VSoftTechnologies/VSoft.CancellationToken It's an abstraction around an event, where the calling thread owns the CancellationTokenSource (which has the cancel method) and the threads are passed the CancellationToken - which has the IsCancelled method you can interrogate, and the Handle that can be passed into api calls that take waithandles (like WaitforMultipleObjects). I have used the cancellation tokens in this library to make http calls cancellable https://github.com/VSoftTechnologies/VSoft.HttpClient It's also used in my https://github.com/VSoftTechnologies/VSoft.Awaitable async/await library (a abstraction over OmniThreadLibrary) All of the above are used in https://github.com/DelphiPackageManager/DPM - any methods that are potentially long running or might need to be cancelled take in an ICancellationToken - so for example in the command line tool, invocking Ctrl+C does this class procedure TDPMConsoleApplication.CtrlCPressed; begin FLogger.Information('Ctrl-C detected.'); FCancellationTokenSource.Cancel; end; That's all that's needed (from the outside at least) to cancel the task - and then in the tasks we pass the cancellation token function TInstallCommand.Execute(const cancellationToken : ICancellationToken) : TExitCode; begin // code deleted for brevity. if not FPackageInstaller.Install(cancellationToken, TInstallOptions.Default) then result := TExitCode.Error else result := TExitCode.OK; end; and in long running methods or tight loops for platform in platforms do begin if cancellationToken.IsCancelled then exit(false); ... or objHandles[0] := processInfo.hProcess; objHandles[1] := cancellationToken.Handle; { Wait for Something interesting to happen } waitRes := WaitForMultipleObjects(2, @objHandles, False, timeoutDuration);

Doesn't work well on this project - feel free to analyse my code and tell me what I did wrong 😉 https://github.com/DelphiPackageManager/DPM If the code is too complex for the tooling, then the tooling needs improving, valid compiling code should not be a problem.

It doesn't work if your search path only has the dcu's or dcp's - which if you use runtime packages is quite likely. I have turned LSP off, but sadly 10.4 cripples the old code insight somewhat and navigating my code has become a real chore.

This is not a registry issue.. it's a bug. I am seeing these issues all the time with 10.4.2 - before I installed I removed all trace of 10.4.x from the registry and the file system.

"I:\GExperts\Projects\DelphiXx104Sydney\GExpertsRS104.dproj" (rebuild target) (1) -> (_PasCoreCompile target) -> I:\GExperts\Source\UsesExpert\GX_UsesExpert.pas(374): error F2613: Unit 'GX_StringGridDrawFix' not found. [I:\GExpert s\Projects\DelphiXx104Sydney\GExpertsRS104.dproj] 0 Warning(s) 1 Error(s) The unit is there, I added it to the project and was able to build. This build seems to have fixed the assertion error I was seeing during shutdown 😉