Leaderboard

For years LSP has been broken on our very large code base. The main problem being "Find Declaration" is non-functional. We also experience problems when switching between Win64 and MacOS build targets; usually doing so without cleaning the project results in the IDE crashing or the compiler crashing or both. I complained about this earlier today in this post: Today, I was stepping through code in our MacOS build when I noticed that the IDE was taking me to the wrong source file. That clued me into what was going on. This project has about 40 local copies of Delphi source files to fix various bugs and add some needed access to private fields, etc. (Trust me, we hate to do this, we don't want to do this, but when the FMX code base assumes only one thread will ever want to use bitmaps and stuff like that, we have no choice). Of course these local copies appear first in the search path. This naturally necessitates that the other source files are rebuilt, and they are listed in the search path, lower down. The compiler works perfectly fine; our modifications are built without issue. But the IDE and LSP hate this. While stepping through code, it took me to the original FMX.COntrols.pas file, not the local copy that is being compiled into the build. No amount of tweaking the search path or browsing path helped. This got me thinking that this could be related to code navigation issues. So I went into the Rad Studio installation folder and renamed all of the source files for which we have a local copy, so that it would be impossible for the IDE or LSP Server to reach them. And like magic, every single problem I have been having with code navigation suddenly went away. Even switching between MacOS and Win64 build targets and compiling became a seamless operation. So, it appears clear that the LSP Server and IDE do not take the same clues as the compiler or linker or whatever when it comes to search paths. And chaos ensues, due probably to incompatible interfaces that exist between unmodified fmx classes and our local forks. Now I could be overstating the effectiveness of this fix, but I spent an hour doing things I know break the IDE and they all worked. The problem is now I have gone nuclear on the Delphi source folders and no other projects can use them. What I would like to do is have a different copy of the BDS /source/ folder that is used for this project. But we already know a wholesale copy into the search path won't fix it, because those files are already there. We need the IDE to treat a different folder as canonical for $BDS/source. I already use the -r command line switch for the IDE to isolate this project into its own registry hive, but I could not find a way to override the BDS variable (nor do I think that is the right solution). This brings me to my question -- going to Tools/Options and trying to override the BDS environment variable creates an error since it is "built-in." My current solution is clunky -- maintain two source copies of the BDS source folder, one with all the files and one with files removed that we have local copies of -- and switch between the two depending on what project I am working on. But is there a way to tell the IDE and LSP Server to use a different source folder? (Probably not, because if so, it would already be working based on the project settings, LOL!) If I can get time I may try to make a small project that reproduces one of these problems, but this is a million+ line project and it could have to do with a combination of factors, not just the fact that we have local copies of stuff like FMX.Controls with incompatible interfaces.

Introducing the first RAD Programmer Coding Challenge! Check the blog post for details. https://ideasawakened.com/post/rad-programmer-challenge-number-1-minesweeper-game-build

RegEx?

Indeed there are: Set TControl.RaiseOnNonMainThreadUsage := True This will raise an EInvalidOperation when CheckNonMainThreadUsage is called for a control. This is automatically done inside CreateWnd.

@All Thank you all for the interesting feedback. In the meantime I tried to get a "first opinion by embt" as well. Depending on that answer, I will raise then the necessary report(s) and link the number(s).

After installing the patch most of the packages compiled with the unpatched version must be re-compiled to work with the patched version.

Create an Option Set with the appropriate entries and add that to each project as reference. Then you really have only one place to change that even works when the project is opened in an IDE using another registry key, being another version or residing on a different system - all assuming that the paths actually exist. Personal preference and the fact that I work for different customers with different sets of used libraries. I just don't want to clutter the search path with unneeded entries.

Strange how that triggers a an OCD response in me when I see it.

Can I participate with a program written 25 years ago? https://github.com/MarcoDelphiBooks/MasteringDelphi5/tree/master/WebBonus/22/MINES

The crazy things we do for our beloved LSP 🙂 _________ I feel you. We are in the same situation - copy of vcl.grids. LSP acts strangely, exactly as you described. It is mostly unreliable or take ages to respond. Question: Why don't you let all projects use the modified Delphi files? Then you don't need the two copies.

(On a side note, you also don't need a semicolon if the next word is "end". If it's known, just ignore me.)

I see the same in the D12.3 source, but no errors show in the IDE. I copied the source to another unit and compiled it and it doesn't care about semi-colons for external function declarations - not even for those with the delayed keyword. Bug or feature? I don't know, but it certainly is not consistent with the rest of the language.

RSS-3125: Add Option to edit DCC_ResourcePath

That's the problem when talking to non native speakers. They might use words that in their mind mean something very different than in yours. I've definitely been there and done that.

The actual wording is: If that means replacing the current system with a completely new approach is debatable.

Not quite, that setting is stored as BRCC_IncludePath. DCC_ResourcePath is indeed the correct way to provide the paths to look for the DFM resources. Unfortunately there is no UI to edit that. Manually editing the dproj file adding a node like <DCC_ResourcePath>..\lib\Source;$(DCC_ResourcePath)</DCC_ResourcePath> under the appropriate PropertyGroup will make the DFM files located in ..\lib\source to be found without exposing the PAS files in that folder.

There are always remote connection possibilities as a compromise. I firmly believe an unfixed product can cost more than a trip for two guys, that know their stuff, to find out what the hell is going on.

Thank you to everyone who suggested improvements to our pre-release versions. We have now officially released pasfmt v0.4.0! For this release, we have made the following improvements: Case statements can now be formatted inline - example Simple conditionally compiled code can now be formatted inline - example Formatting of package conditional directives in the style of RAD Studio - example Various bug fixes (for more information, see the changelog) Alongside this, we have also released pasfmt-rad v0.2.0. Now featuring bookmark and breakpoint relocation across formats.

I see that there are no formatting settings, and the code is written in Rust. I’m wondering who else might find this useful besides your internal team? What made you choose Rust for a Delphi code formatter? Just wanted to try out Rust, or was there more to it?

Can you please elaborate this? Maybe a short article on this topic. P.S. I've noticed that there have been several interesting Delphi projects from Brazilian developers lately. Skia for Delphi, D2Bridge Framework are the most notable.

v6.4.0 Beta 1 We are pleased to announce one of the biggest updates of Ski4Delphi! For the first time in Delphi's history, we have a C++ library statically linked to a Delphi application on Windows, removing the dependency on sk4d.dll. In addition, we have updated the Skia library from version m107 to version m132. After a long research and experiments, we were able to understand the "limitations" of the Delphi linker and build a pre-linker for C++ libraries that would get around these limitations, producing objects that are fully compatible with Delphi, which could be used to statically link not only Google Skia, but any C++ project in Delphi on Windows. Source: github.com/skia4delphi/llvm-project This is still a beta version, but all our tests have passed and there are no known issues regarding the new changes. Enjoy! 🙂

A TList<T> has a constructor overload that takes a comparer (IComparer<T> instance) to use for sorting and searching the list by default. The Sort method also has such an overload. You use TComparer<T>.Construct() to fabricate a suitable comparer on the fly, providing an anonymous method that does the actual comparison of two items in the way you want the sort to go. This anonymous method has to "know" the record type in question, so you can directly refer to the fields of the two items passed to it. Forget about pointers, you do not need them to work with generics.

Hi while testing a Delphi syntax parser, we struggled over a few line in the Delphi "Winapi.ShellAPI" interface. In opposite to 99.99% of similar declarations, 3 lines have no semicolon at the end function SHLoadNonloadedIconOverlayIdentifiers; external shell32 name 'SHLoadNonloadedIconOverlayIdentifiers'; function SHQueryRecycleBin; external shell32 name 'SHQueryRecycleBinW' function SHQueryRecycleBinA; external shell32 name 'SHQueryRecycleBinA' function SHQueryRecycleBinW; external shell32 name 'SHQueryRecycleBinW' function SHQueryUserNotificationState; external shell32 name 'SHQueryUserNotificationState' delayed; the 3 lines in the middle have no ending ';' (lines 1825 - 1827 for delphi 12.2). Is this really a valid Delphi syntax or just a glitch in the compiler?