Vincent Parrett

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 😉

That's correct. I suspect that error was actually caused by having FixInsight installed. After removing it I no longer see the error.. I forgot that I removed it!

Hi All Small progress update on DPM - https://github.com/DelphiPackageManager/DPM - some tweaks to make it possible to use DPM with projects that use runtime packages. v0.1.54-alpha Release https://github.com/DelphiPackageManager/DPM/releases/tag/v0.1.54-alpha Package compilation will now build version info if the package dproj has it enabled. There doesn't appear to be a way to pass that info into msbuild, so I plan to look at updating the dproj file with the correct version info before compilation. Implemented Copy Local feature for runtime packages. For projects that use runtime packages, dpm packages that produce runtime packages will be copied to the output folder. Copy Local is still a little rough around the edges... it doesn't detect if the project actually references the bpl's - that's more difficult than it sounds due to differences between dcp and bpl filenames (libsufffix comes in play here). So for now, you may end up with extra bpl files in your output folder if you use runtime packages. Fixed project group support on install command. Improved handling of relative project file paths. Cleaned up logging. Added batch file for downloading dev dependencies (only needed for developing DPM).

Thanks. Only need the base config.. at the moment I'm only building the Release config, if users need to debug then there is the option to usesource when installing (adds the source to search paths, as it did before I implemented compilation). I'm using msxml already in the project as I prefer to use XPath for selecting nodes. I will take a look at this in the next few days. I'm migrating FinalBuilder 9 dev over to using DPM (for non visual libs for now) so I'm dogfooding as I develop.

I do, but there's always a chance to learn from others and improve my code 😉

Definitely interested. I have code already in DPM for reading values from the dproj (dealing with the awful config inheritance setup) but not for writing... the code is a hacked version of what we have in FinalBuilder, which is far from perfect.

I know how to make it compile, just pointing out that the project no longer compiles as checked out from svn (it usually does).

@pyscripter I'm just pointing out that this bug is not isolated, but is a symptom of an endemic issue with vcl styles in general. I'll leave it at that.

This whole saga is typical of the VCL Styles support - in short, it's a mess. My guess is they really don't have anyone inhouse that is an expert with this stuff, so various people (contractors?) tinker with individual issues without an overall picture of things and with an impact analysis. You only have to look at how double buffering is handled 15 different ways in the vcl for various controls. Then there's the overpainting that happens when controls are resized (the whole form is repainted for each control). https://quality.embarcadero.com/browse/RSP-30639 And the response to it has been laughable at best. They "fixed" the design issue by tinkering with one affected control (TMemo) but left the rest (citing the need for interface changes) - but now they expect us to enter separate issues for each affected control! I suspect that is so they can split the tasks up to different people... so we can get more of the same tinkering. Seriously, if you are not already using VCL Styles, then don't bother with it.