Dave Novo

The purported disadvantage of NxHorizon needing more boilerplate code can be mitigated somewhat if you have the AI write the boilerplate.

For refactoring existing code I have not gone as far as this. This is useful. What I often do is refactor a single method, and extract the common code to the method I want. I then leave the old code in, commented out, and my new code. Then I tell Claude to look at the old code, look at how I refactored it, and then apply this refactoring as needed to other methods in the unit. It is amazing how accurate it can be in that case, even often finding situations that were not exactly the same but similar, and making adjustments to accomodate and refactor that part as well. I saved tons of very boring and error prone work. Of course, I review the code afterwards, run the test cases etc, but Claude really shines in this kind of boring refactoring.

The only way to know your code works is to test it. I am confident the code works if the test passes. If you feel it is sufficient to rely on the Delphi documentation, that is your personal choice. I can find tons of examples where the Delphi documentation was flawed, or bugs in Delphi where the docs were correct and specified what should happen, but it did not. My point is everyone draws the line somewhere, but that line is arbitrary and based on personal experience, and a sense of how critical the functionality is. You draw the line that if the web says something, and you read the documentation and it seems to agree, then use it. (of course I am exxagerating here, I doubt a developer of your experience would actually do that, but that is what you suggested) @dummzeuch suggests to draw the line when you "understand it". Of course the degree to which one can understand any code depends, in general, on how long one wants to spend on it. Does "understanding" mean reading the docs, reading the source, trying various permutations of the code, making a test, all of the above, who knows? I suggest that much of the time what people actually do with AI and code from the web is try the suggested thing, and if it works, they use it. Of course, if they are in a section where the code needs to be utmost performant, maybe you have to spend more time. Or if there are other particular requirements then you spend more time. But if the AI/Web code works for you, then fine. Every minute you spend perfecting a line of code, is a minute you don't spend writing another line of code. Its always a balance and I shy away from blanket statements that are intended to apply to any situation. Personally, I have had a lot of success with AI and with taking code snippets from the web. Sometimes what you are doing warrants a deep look. Other times, not.

So if I find a code snippet on the internet how to use the Format function to format floating point numbers and it recommends %8.2f, I should then read the source code of the format function in Delphi and make sure that I understand the entire method to ensure that the suggestion is correct. Maybe you do that, and if you do that is awesome for you that you have the time to do so. Of course, there is the possibility that using %8.2f can cause a buffer overflow and then I am opening the door to a zero day exploit on my application. Of course I understand the Claude code snippet. It is pulling the info from the About box. What is not to understand? Unfortunately, I do not have as much time to analyze every method of Delphi source, and analyze the ramifications of every code snippet I use from the web in Depth. In the example above, I would judge that pulling information from an About box is likely not the most efficient way to do it, also is not likely to introduce any security problems. Given the lack of any documentation on the ToolsApi I would also realize it would take a significant amount of time to figure out the "right way". Conclusion: try the code above and hope it works 🙂

HI Anders, Of course the about box gets its version number somewhere. The point being, do I care? Of course, I could spend another 5-30 minutes digging through undocumented IDE ToolsAPI code. Or maybe better yet, spend 20-45 minutes digging through 100 false starts on google results, stasck overfloat posts etc., only at the end of the day to learn the proper API call to execute to get the version number. Then, I can brag to all my friends that I still remember how to "think", as if reading through undocumented IDE Services code is a hallmark of a great thinker. Or I can take the code above (presuming it actually works) and move on to building the tool I actually want to build. By this logic, if someone has posted the code above on StackOverflow and it popped up someone's first stack overflow query, and they used it, and it worked as far as they needed it to, would that person still have forgotten how to think? One could easily argue that people who ignore AI, and spend 30 minutes trying to accomplish a task that AI gets an answer in 10 seconds have forgotten how to think. Of course, with all the usual caveats that often AI is not correct, especially on obscure questions that it does not have a lot of training material on the web. But often it is correct, at least correct enough for you to move on and do what you really wanted to do in the first place.

This is what Claude said. No idea if its true or not since I have never looked into this procedure GetCompleteVersionInfo(out ProductName, Version, BuildNumber: string); var Services: IOTAServices; AboutBox: IOTAAboutBoxServices; FullVersionString: string; Parts: TArray<string>; begin ProductName := ''; Version := ''; BuildNumber := ''; Services := BorlandIDEServices as IOTAServices; if Assigned(Services) then begin ProductName := Services.GetProductIdentifier; Version := Services.GetIDEVersionString; end; AboutBox := BorlandIDEServices as IOTAAboutBoxServices; if Assigned(AboutBox) then begin FullVersionString := AboutBox.GetVersionString; // Parse the build number from the full version string // Format is typically: "Embarcadero® Delphi 10.4 Version 27.0.40680.4203" Parts := FullVersionString.Split([' ']); if Length(Parts) > 0 then BuildNumber := Parts[High(Parts)]; // Get the last part end; end;

Has anyone noticed any improvements in debugging inline variables in Delphi 13? In Delphi 12.3 it is basically broken, and does not work for me 90% of the time. Always said "undeclared identifier" and other nonsense while trying to debug.

@david berneda - this is where AI shines. Just fire up claude code and ask it to insert the include directive in a specific spot (i.e. "insert this include statement xxxxx right after the unit specifier at the top of units that start with the letter q in this folder" and it will just do it.

The vmt of all Delphi classes has vmautotable that is not used. I have patched a particular class vmt and in the autotable slot and stuck a reference to an object in there. So both of your units can check that reference on some class from the vcl that you pick. Then they can patch the class. I dont remember the patching code but if you cannot find it on the web let me know and I can dig it up.

@Uwe Raabe - done. I did not even know I could browse other issues because I can only access anything about the portal by selecting the "my account" icon on the top right. But at least now I can see other issues.

Interestingly, @Stefan Glienke reported a similar issue for TList<T> many years ago, that was implemented. So maybe there is hope ([RSP-21316] TList<T>.InsertRange lacks optimization for passing another TList<T> - Embarcadero Technologies) I did create a new issue in the new quality portal RSS-4020. However, it seems impossible for me to browse other people's issues on this new portal so not sure anyone else can see it.

Of course, it is one of the problems with the current TStrings. It was simply not designed for efficient bulk operations. For example, as long as I was notified which items were going to be removed/extracted/inserted either before or after the actual removal/extraction/insertion then I could handle whatever I needed to do. I dont need to be notified one item at a time. I am mainly wondering if in the last 30 years anyone had written a robust implementation that handled these bulk operations. I could spend a few hours/day creating something based on IList<string> and copy/pasting relevant code from TStringList to handle the missing/useful functionality but again, just wondering if anyone did so already.

Hi Anders, Of course I can hack the FList, hack the Capacity, hack the count, hack the Notify and and/or reimplement the entire StringList. Just wondering if anyone has done so already.

Hello, Amazingly, after so many years, Delphi still does not have an effective TStrings implementation of InsertRange (insert a range of strings at a specified index), DeleteRange (delete a range of entries at a specific index). Of course IList<string> in Spring4D has these, but then you lose many of the helpful things that TStrings does have (like .CommaText, .Text, BOM handling and others). I see that Spring4D has a TStringsAdapter and implements many of the missing methods, but does so following the TStrings way (i.e. implements insertRange by calling FStrings.Insert over and over in a loop which is moving the memory around many times). Does anyone know of a TStringList replacement that keeps all the features of TStrings but adds more robust insertion, deletion etc in an efficient manner?

Hi Anders, Out of curiosity, what are the most effective ones? Based on your comments I did a quick google/AI search and both seemed to indicate that if you expect a high level of matching across your static set of strings (i.e. when you test a string against your set you expect a match most of the time, which is what I would guess based on a case statement of strings) then hashing is an effective algorithm. If you expect a lot of misses, then a Prefix Tree is a better choice because you don't have to read the entire string all the time. But Prefix tree is slow in the event you match a lot, since you have to read the entire string anyhow.