Mark NZ

Yep, sometimes they just close as cannot reproduce and occasionally something actually happens. I raised an issue with a few days ago with 12.3 AV's occurring when swapping between RDP/local that happens often but I don't have steps to be able to do it on demand, have previously logged or commented on a similar problem with info that I suspect it's related to resolution or dpi changing during the connection process. Created the issue as I had a call stack which could be of help for diagnosis, adding extra logging etc. I don't normally bother with logging issues as Embarcadero quality, support and fixes are so poor (and that's me being generous, internally I swear about the product and the support)

Once it's opened be prepared for multi year waits 😞

For us many features (including those 2) are broken or work poorly in many recent versions of Delphi (10.x onwards?) when working in large projects, still so in Delphi 12.3

They added LSP logging which could be turned on for tracking down bugs they couldn't reproduce (similar to what we do at times for knarly customer bugs that we can't reproduce), turned it on, gave them the logs, from memory no related fixes were forthcoming. I've also looked at their general source base (eg VCL) given them the bug and the fix and not had them actioned 😞

They say that but in my opinion it doesn't appear to have good practical results, yes they do have fixes but there are LOTS of outstanding issues that really annoy people and the bugs have been increasing at a substantially faster rate than are fixed for many years- it was really telling viewing the raised vs resolved Jira graphs on the old quality portal. It was also pretty bad seeing the number of "resolved/fixed" bugs that were simply closed because Embarcadero couldn't reproduce while customers were still reporting they were a problem. Additionally a number of their "fixes" don't properly fix the problem or introduce new bugs. From the outside it appears like they don't have much in the way of development resources, especially experienced ones that know the code really well.

I agree, followed by LSP then the IDE - a huge FIXES focus based approach would be good for a few releases. It's a bit hard for me to tell how well LSP is working as am doing most pas file editing using VSCode with LSP and CoPilot, anecdotally I think LSP works better there. Could be that LSP is okay and it's the Delphi IDE failing when I'm having problems with code jumping, editing etc

I've just created a new post with info that may be of interest, and hopefully others can add to it https://en.delphipraxis.net/topic/13177-vscode-for-a-delphi-ide/

I've had a couple of requests for information on what settings etc I use to edit, compile Delphi from VSCode and I'm hoping others can add insights on what they use. I don't have extensive experience with VSCode and moved to it last year for the following reasons, in priority order To work around a lot of problems we encounter with the Embarcadero IDE with our projects To have a consistent IDE between Linux C work and Windows Delphi To trial effectiveness of CoPilot after co-workers said how great it was. Unfortunately I haven't done a clean VSCode setup and notes record from scratch so these aren't definitive notes. I do some C coding on a Linux VM for a real time control app as well as Windows Delphi, hence C/C++ extensions Extensions I have following extensions installed C/C++, C/C++ Extension Pack, C/C++ GNU Global, C/C++ Themes, CMake, CMakeTools, CodeLLDB Delphi LSP, Insert GUID, #region folding, #region tree view GitHub Copilot GitHub Copilot Chat Numbered Bookmarks Pascal, Pascal Formatter SVN Todo Tree WSL XML The following extensions are installed but disabled #region tree view Auto-align Better Align My notes say I installed the following but they aren't there now Delphi Extension Pack which installs Pascal (still installed), Numbered Bookmarks (still installed), Delphi Keymap, Delphi Themes, CodeRunner, MakeFile, Note on CoPilot, I'm a greybeard (although haven't had a beard for many years) and have been amazed at what it suggests, can do and some of the inferences it makes. Sometimes it's mind boggling, eg coming up with a correct suggestion for something you're typing that's not related to anything else in the code nor anything else that you would think was commonplace. You do need to check it carefully though, hallucinations, subtle and not subtle mistakes but well worth the time it can save. Editor Tab colors I use dark themes. It can be difficult to see which tab item in the tab bar belongs to the currently visible file in the editor, especially when jumping to function definitions etc. To add colorization open settings and search for colorcustomization Under workbench: Color Customization click on Edit in settings.json Example settings 1) black inactive tab header with active tab having medium blue background and light blue activeBorder and activeBorderTop "workbench.colorCustomizations": { "tab.activeBackground": "#0091ff56", "tab.activeBorder": "#00aaff", "tab.unfocusedActiveBorder": "#000000", "tab.activeBorderTop": "#00aaff" // Active Tab Top Highlighting }} 2) black tab headers with red activeBorder and activeBorderTop "workbench.colorCustomizations": { "tab.activeBackground": "#11ff001a", "tab.activeBorder": "#ff0000", "tab.unfocusedActiveBorder": "#000000", "tab.activeBorderTop": "#ff0000" // Active Tab Top Highlighting } VSCode for Delphi Programming Here’s Embarcadero’s page on setting up DelphiLSP with Visual Studio Code https://docwiki.embarcadero.com/RADStudio/Athens/en/Using_DelphiLSP_Code_Insight_with_Other_Editors Generation of a .delphilsp.json file from Delphi is controlled through Delphi Options, Editor->Language->Code Insight->Generate LSP Config Type LSP into VSCode settings to to Delphi LSP settings and set the location of the project delphilsp json file Preferences / Settings I don't like the LSP suggestion autocomplete happening when I press enter, for example by default when I type begin and hit enter it replaces it with BeginGlobalLoading To prevent this I leave suggestions on but turn off ENTER as a completion shortcut ( TAB can still be used). Go to settings File > Preferences > Settings > Text Editor > Suggestions > Accept Suggestions On Enter > Select on, off or smart. ("Controls whether suggestions should be accepted on Enter, in addition to Tab [...]" Building via VSCode tasks I suspect creating an extension to build by normal VSCode method would be not difficult to do but haven't had time to investigate. Currently I build using tasks and it's a bit messy but is functional. If you were only building a single DEBUG config using this method it would be simpler as you wouldn’t need to choose the config each time you build or run, we build different configs for different emulations. I was hoping we could somehow easily preselect the emulator config we want to use at the start of a session and then just build/run each time (eg via <shift><ctrl>B) without having to select the config but haven't had time to look into that further. We already had batch files setup for release building done outside of the IDE, ie Crbuild.bat, and use these for building via VSCode. tasks.json needs to go in the .vscode folder, eg if I'm working on the TC7\TC7.dproj project then in TC7\.vscode folder, assuming TC7 is the workspace folder you have open. <shit><ctrl>B will build or you can choose to run your desired task from Tasks: Run Task Sample tasks.json from our wiki /* Tasks definitions for compiling and running TC7 in VS Code. You can use this file for .vscode/tasks.json file in a workspace, or as "User level tasks" (indepedent of workspace). This tasks file allows to compile /run / compile+run the TC7 project using Wrist Bevel Emulator associated with the currently open file. Need to look at how to handle building using different emulators. One option could be to open a file in the emulator folder and then use ${fileDirname}, can set cwd using the following "cwd": "${fileDirname}" See https://go.microsoft.com/fwlink/?LinkId=733558 for the documentation about the tasks.json format. */ { "version": "2.0.0", "inputs": [ { "id": "emulatorFolder", "type": "pickString", "description": "Select the emulator folder", "options": [ "RELEASE", "DEBUG", "abs encoded 12 magnet twin sled PUG", "700 Towers", "725 K4100 wrist bevel", "wrist bevel x86", "K5100 wrist bevel and unloader" ], "default": "K5100 wrist bevel and unloader" } ], "tasks": [ // Compile and then Run the TC7 project of the currently open editor file. // This is like F9 in Delphi. { "label": "(TC7) Compile And Run", /* We use VS code "dependsOn" feature to run 2 tasks in a sequence. This is better than using shell command with && which is not universally supported by PowerShell. */ "dependsOn": [ "(TC7) Compile", "(TC7) Run" ], "dependsOrder": "sequence", "group": { "kind": "build", } }, // (Re)build the TC7 project { "label": "(TC7) (Re)Build", "type": "shell", /* Compile in debug mode using TC7 build tool (calls msbuild under the hood). */ "command": "${workspaceFolder}\\crbuild.bat", "args": [ "-ProductVersion", "23.0", // "-config", "DEBUG", "-config", "${input:emulatorFolder}", "-nolog", "-target", "rebuild" // "-OutDir", "${workspaceFolder}\\Output\\EMUs\\${input:emulatorFolder}" ], "options": { "cwd": "${workspaceFolder}" // "cwd": "${workspaceFolder}/Output/EMUs/${input:emulatorFolder}" }, "group": { "kind": "build", "isDefault": false }, "problemMatcher": { "fileLocation": "autoDetect", //["autoDetect", "${workspaceFolder}"], "pattern": [ { /* Match lines like xxx.pas(123,456) Fatal: some message Deliberately avoid matching summary line like xxx.pas(2201) Fatal: There were 26 errors compiling module, stopping Deliberately avoid xxx.pas(648,15) Error: Found declaration: ... because they only make sense when connected to previous error message, and VS Code reorders them. Test: https://regex101.com/ (ECMAScript flavor) */ "regexp": "^([^\\(]+)\\(([\\d+,]+)\\)\\s+(Fatal|Warning|Error|Note|Hint):\\s+((?!\\(10026\\) There were)(?!There were)(?!Found declaration: )(?!\\(5088\\)Found declaration: ).*)$", "file": 1, // location may be line or line+column. "location": 2, "severity": 3, "message": 4 } /* , { // Match lines like // Compiling xxx.pas "regexp": "^(Compiling) ([^\\s]+)$", "file": 2, "message": 1, "kind": "file" } */ ], /* We need non-empty owner to hide older problems on recompilation. See https://github.com/Microsoft/vscode/issues/50448, https://github.com/microsoft/vscode/issues/66982 */ "owner": "Kinetic Engineering" } }, // Compile the TC7 project { "label": "(TC7) Compile", "type": "shell", /* Compile in debug mode using TC7 build tool (calls msbuild under the hood). */ "command": "${workspaceFolder}\\crbuild.bat", "args": [ "-ProductVersion", "23.0", // "-config", "DEBUG", "-config", "${input:emulatorFolder}", "-nolog", "-target", "build" // "-OutDir", "${workspaceFolder}\\Output\\EMUs\\${input:emulatorFolder}" ], "options": { "cwd": "${workspaceFolder}" // "cwd": "${workspaceFolder}/Output/EMUs/${input:emulatorFolder}" }, "group": { "kind": "build", "isDefault": true }, "problemMatcher": { "fileLocation": "autoDetect", //["autoDetect", "${workspaceFolder}"], "pattern": [ { /* Match lines like xxx.pas(123,456) Fatal: some message Deliberately avoid matching summary line like xxx.pas(2201) Fatal: There were 26 errors compiling module, stopping Deliberately avoid xxx.pas(648,15) Error: Found declaration: ... because they only make sense when connected to previous error message, and VS Code reorders them. Test: https://regex101.com/ (ECMAScript flavor) */ "regexp": "^([^\\(]+)\\(([\\d+,]+)\\)\\s+(Fatal|Warning|Error|Note|Hint):\\s+((?!\\(10026\\) There were)(?!There were)(?!Found declaration: )(?!\\(5088\\)Found declaration: ).*)$", "file": 1, // location may be line or line+column. "location": 2, "severity": 3, "message": 4 } /* , { // Match lines like // Compiling xxx.pas "regexp": "^(Compiling) ([^\\s]+)$", "file": 2, "message": 1, "kind": "file" } */ ], /* We need non-empty owner to hide older problems on recompilation. See https://github.com/Microsoft/vscode/issues/50448, https://github.com/microsoft/vscode/issues/66982 */ "owner": "Kinetic Engineering" } }, // Run the previously compiled TC7 project. // This is like <ctrl><shift><F9> in Delphi IDE. { "label": "(TC7) Run", "type": "shell", "command": "./TC7.exe", "args": [ "/no_scale", "/t:0", "/l:105", "/portrait", "/no_polling_err", "/moveable_display", "/web_debug:..\\Web\\Resources\\" ], "options": { "cwd": "${workspaceFolder}/Output/EMUs/${input:emulatorFolder}" }, "group": { "kind": "build" } } ] } A sample crbuild.bat is as follows @echo off set BUILD_TARGET_TYPE="rebuild" set BUILD_CONFIG=Release set OUTPUT_TO_LOG=Y set OUTPUT_FOLDER_PARAM= rem Set the default Delphi version to compile with, 22.0 => Delphi 11.x, 23.0 => Delphi 12.1 set ProductVersion=22.0 :argsloop IF NOT [%1]==[] ( IF /i [%1]==[-config] ( SET BUILD_CONFIG=%2 shift ) IF /i [%1]==[-ProductVersion] ( SET ProductVersion=%2 shift ) IF /i [%1]==[-Target] ( SET BUILD_TARGET_TYPE=%2 shift ) IF /i [%1]==[-nolog] ( SET OUTPUT_TO_LOG=N ) SHIFT GOTO :argsloop ) set BUILD_TYPE=DEBUG set BUILD_CONFIG_UNQUOTED=%BUILD_CONFIG:"=% if /i ["%BUILD_CONFIG_UNQUOTED:~0,7%"]==["RELEASE"] ( set BUILD_TYPE=RELEASE ) set DELPHI_VARS_PATH="C:\Program Files (x86)\Embarcadero\Studio\%ProductVersion%\bin\rsvars.bat" call %DELPHI_VARS_PATH% rem build using msbuild set MSBUILD_CMD=msbuild TC7.dproj /t:%BUILD_TARGET_TYPE% /p:config=%BUILD_CONFIG% echo Running %MSBUILD_CMD% if /i "%OUTPUT_TO_LOG%"=="Y" ( %MSBUILD_CMD% 2>&1>>".\Output\crbuild.log" ) else ( %MSBUILD_CMD% ) Debugging Not working yet, would like to get it working for simple debugging and have only spent a little bit of time on it. Whether it's overly usable for inspecting values/classes etc though will be interesting - but then we have a lot of problems with Delphi debugging inspection etc of things not working. Have tried using lldb setup via the following VSCode launch.json setting file but lldb won't run the exe (eg running lldb from command line). WinDBG will run the exe but have only briefly tried it { "version": "0.2.0", "configurations": [ { "name": "Launch Delphi TC7 L102 Maxphotonics", "type": "lldb", "request": "launch", "program": "${workspaceFolder}/Output/emus/L102 Maxphotonics/TC7.exe", "args": ["/no_scale /t:0 /l:105 /portrait /no_polling_err /moveable_display /web_debug:..\\Web\\Resources\\"], "cwd": "${workspaceFolder}/Output/emus/L102 Maxphotonics", "stopOnEntry": false, "preLaunchTask": "Echo vars" } ] }

Used it for a few minutes and sigh bugs we've been waiting for years for fixes still there. Top toolbar drawing problems, already had an av plus freezes and unusable functionality (eg context menu Find Declaration, Find, Find Symbols, Refactor) 64bit IDE won't debug the first 64bit project of ours that I tried. Was hoping things would improve, luckily VSCode is more productive and usable with our code bases, unfortunately still need to use IDE for forms editing and for debugging as haven't got lldb debugging of Delphi code working yet.

I prefer to have GExperts/CNPack to add missing IDE functionality whenever possible but we have problems with/without it, most of us normally don't have extra components apart from VirtualTreeView, a small number of our own GUI controls for forms and our own internal debug evaluators installed (they're something else that's been a problem to get working in various Delphi versions due to Delphi bugs). If you only use 32bit then that would have saved you a LOT of problems with the debugger over the years, yes there have been problems with inline variables but they are pretty much okay now. The IDE AV's when compiling (compile is almost useless, need to use build). We've had to switch between Delphi and msbuild at times on some of our projects to get them to build and currently use a mixture. Problems with 4k screen, toolbars corrupting, code jumping not working, code insight, ide crashes (they can be occasional but have recently had days where I gave up editing in Delphi and used another editor as was happening a lot with certain files), IDE not responding for seconds (eg frequently with find in files), tools that don't work (eg Find Class which crashes, Find References which is mostly greyed out, Refactor which misses things), debugger showing incorrect line in code (usually be a few lines but can be 20 or so out), debugger not able to show/evaluate values, the Parnussus parallel debugger looked great but was an unusable failure, we gave up on the Delphi parallel library and use OTL, use another JSON library due to bugs encountered in the Delphi one. Luckily we've been able to generally patch the Delphi libraries when bugs have been found that effect us - unfortunately got a new one in Delphi 11.3 System.pas where they've made a notification change that causes a runtime crash for us which I think is a bug but have left it to my co-worker to investigate and try and build a simple test case for Embarcadero. This bug might be harder to work around as we can't simply put a patched System.pas into our patches search path folder as Delphi won't allow you to (re)compile System.pas (that applies to several other units as well). Bugs take years to get fixed (or don't get fixed) when given simple reproduction steps and/or a patch to fix them. We had one where they relatively quickly 'fixed' a bug and they included incorrect comments and introduced a new obvious memory leak.

We have smaller projects ranging from 500 000 lines to larger ones around 2.4 million, about 30 regularly used projects and code insight problems with most of them. Code insight is getting better but the whole IDE is bad enough that two of the 5 devs here have given up on it and are using Visual Studio Code for editing Delphi and only switch back when they really have to for debugging or form editing. I've been working on a a non Delphi Linux project for large chunks of the past year so haven't invested any time in switching but have tried VS Code and I think once I learn to use it quickly I'll switch as well as it doesn't crash like the Embarcadero IDE. If VS Code had a form designer and Delphi debugger it would make the Delphi IDE completely redundant, especially if the debugger worked properly (Embarcadero debugger is frequently problematic for us in x64 which is the platform we need to use, again better than it was a few years ago but still lots of problems)

For us sometimes code completion works in Delphi (very small projects), that's the paid enterprise version, most of the time it doesn't - you just get use to it with Delphi. Yes it and lots of other bugs are frustrating but if you're stuck with a legacy code base you don't have much choice until the cost of using it just gets too great 😞

I can confirm that in my case the compiler compile AV's happen without switching between project/build configurations (and over multiple Delphi versions), hopefully the 32/64bit is a more reliable trigger though for the same issue (might make it easier to find).

I also get a large number of AV's when compiling via the IDE, started prior to Delphi 11.1, still a problem in D11.3, just got into the habit of always building. We do use MSBuild (think this was due to build errors if we didn't). I encounter a number of other errors with the IDE and it's not feasible to spend time attempting to chase them down 😞, I have at times attempted to reproduce some of bugs with simple reproductions steps and have raised Jira issues for these and VCL bugs. Embarcadero have even fixed some of those, the others are waiting for them to look at. I suspect a number of issues are related to project size - and for the person who said to review every line of your code, if we allowed 2 seconds per line that'd be half a year of full time work, for just one of our projects. Yeah, nah. With regards to AV checking I'm going to look at that, we're already be excluding our own source code as have run into a handful of problems with Sophos if we don't.

Marco Cantu's book says it should, page 26 of the 10.4 version It would be very nice if it did work as one of our senior developers who's in charge of a couple of projects is very anti the verbose XMLDoc and is also a proponent of 'well written code self documents' which unfortunately isn't helpful if the code has a mistake and you're trying to work out intricacies of what it is supposed to do or your trying to find the correct method etc out of a range of them. If /// worked he would grudgingly use it. For the rest of our projects we do use the full notation but we have a huge lot of legacy code where it would be nice to replace existing method header comments using braces to just use /// and very quickly have xmldoc working