Vincent Parrett

Yes, that's what I'm doing, not before each form.. just before the first form (splash screen) is shown. I just don't do it in the dpr, since I need to check the user's config to see which theme is selected first. My dpr literally had 1 line (apart from uses etc) begin TIDEStartup.Run(); end. That does mean however that the Appearance node in the project options doesn't show - so I have to manually add the styles to a resource file - not a big deal though.

I do that (well not in the dpr, but before any forms are shown).

Styles cause all sorts of flicker problems - I'm pulling my hair out dealing with flicker that was introduced somewhere between XE7 and 10.4 (I'm upgrading from XE7) - really wishing I had never bothered with styles! FWIW, the IDE also has many flicker issues - the whole VCL/styles thing is a mess, but they can't be bothered to fix it because marketing can't put that "on the box"!

Is the source available somewhere?

I have GExperts (built from latest svn) and fix insight, seeing shutdown issues since installing fixinsight yesterday. Also seeing the occasional issue with GExperts.. but I'm going to blame the IDE because even without these two plugins, it's buggy as hell!

Unfortunately Resharper is a resource hog, and really slows down the IDE. I have not used Rider, but have used some of their other IDE's and found them quite strange to work in. We live in hope!

There's no doubt about that. I use VS a lot, and with CodeRush installed and navigating code is leaps and bounds ahead of delphi.

It works most of the time inside a single unit or even a single project. I wouldn't call a project group a special case though, anyone who works on a non trivial project would be using them.

Yes it could, but it would need to parse all the code.. which would reintroduce the overhead that the LSP is supposed to remove (high memory usage). Writing a complete, fast, memory efficient parser for the purposes of navigation is no trivial task.

I've already been over this with embarcadero people privately (look at the date, here's a clue, it's before the release date) and provided lsp logs etc. Ctrl+enter opens the file open dialog. So does right clicking and selecting Open file at cursor. So for me, 10.4 has completely broken code navigation... which makes it painfully slow to work in. To reproduce, create a project group with a package project, and an exe (that uses runtime packages) and references the package project. In a unit in the exe, add a unit from the package in your uses clause, then try ctr+click. My project as 100+ packages and a few exe projects.. it's not easy to work on with broken navigation.

https://quality.embarcadero.com/browse/RSP-28457 - opened on the 8th May.. read into that what you will.

Nope, not true. It completely fails when the identifier or type in is in another (referenced) project in the same project group. Makes working on a large project quite painful.

A quick look tells me there are other issues with TDirectory.GetFiles - no support for paths longer than MAX_PATH - which windows 10 1607 or later does support. You do have to enable it both on the system (reg key) and per process (manifest option) https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#enable-long-paths-in-windows-10-version-1607-and-later

Thanks for that info! I have been using TDirectory lately, but this thread spiked my interest in looking at how it's implemented.. creating a freeing a TMask for every file/directory is not very efficient.

We see a spike in traffic visiting this post on our site after every delphi release - how-to-fix-your-system-path-after-installing-delphi It's rather sad that it's the second most popular post on our blogs (after the DUnitX introduction post).