dummzeuch

It does indeed. It should also be possible to write a function that reads its own return address from the stack and then returns this value as the result. This then could be passed to GetLocationInfo. I'm not sure how to implement this, but it shouldn't be rocket science. Edit: There is System.ReturnAddress, introduced with Delphi XE2, which gives you just that, so function GetCurrentLineNumber: Integer; var ModInfo: TJclLocationInfo; begin ModInfo := GetLocationInfo(ReturnAddress); Result := ModInfo.LineNumber; end; Should do the trick (untested) Edit: Just tried it. It works, at least in Delphi 10.2. Edit: JclDebug already contains such a function called LineByLevel.

No idea. I currently don't find the time to do anything on it.

I know that GExperts can cause this. Unfortunately I so far was unable to find the actual problem. It seems to be connected with using the formatter very frequently.

dxgettext can translate ressource strings. It does so by hooking several RTL functions, one of them being LoadResString. Last time I looked it only worked for 32 bit Delphi, unless somebody has ported it to 64 bit by now.

I can't be bothered, sorry. I was only "thinking aloud". Maybe I shouldn't have written it as a comment, though.

I wonder how much of the time depends on where the file is read from: RAM Disk, SSD, HDD and for the latter whether it's already in the cache or not. 2 (American billion) = 2.000.000.000 lines of about 15 characters makes it about 30.000.000.000 bytes, that's 30 Gig of data to read, split into lines, then split into name and value and then aggregate by name. 32 bit Delphi won't be able to handle that with Stringlist because it won't fit into memroy, I wonder whether there are any bugs in the RTL that would prevent that with a 64 bit Delphi program. But anyway: Using a StringList is probably not the most efficient way of reading the data. Plain old ReadLn would likely do the trick faster. Some kind of buffering might speed it up and maybe parsing based on a PChar pointer rather than strings. Then selecting a suitable datastructure, probably some hash based dictionary. The rest is not much of a challenge.

There is also Delphi Custom Containers Pack. For some types of components I prefer that over frames.

I was just about to ask the same as @Der schöne Günther: Why did you put those two dots in front of AsString? That might confuse the watch window.

We already had that: It was called Delphi for dotNET. AFAIK the last Version was Delphi for dotNET 2007. Somehow it didn't catch on.

Some parts of the Linux kernel are being converted to Rust. Also, many parts of the Linux distributions are written in Python oder even shell scripts. Some Perl can still be found there too.

Or, if you prefer using the mouse: There are Build Sooner / Build Later entries in the popup menu.

On my computer it works exactly that way. 1200 pixels: 960 pixels: Maybe there is some configuration setting that causes this. I don't remember changing anything though.

It depends on how wide your browser window is. Yours is too narrow, so you get the condensed view. I get that too if I move the browser window to half of a HD monitor -> 960 pixels wide. If I make it a bit wider, I get the full path. That's called "responsive design" I think, and I usually hate it. Be we digress.

Please file a bug report on sourceforge.

That has been the case since forever when using TMemIniFile rather than TIniFile (the latter uses the ancient/deprecated WinAPI Get/SetPrivateProfileString). So if that has changed from 11.3 to 12p1, this probably means that somewhere somebody has switched from using TIniFile to TMemIniFile.

Hm, OK, I could have sworn it said "Update 1" in the about dialog but you are right, it says "Patch 1". So, I stand corrected.

I my opinion Delphi 12 + Update 1 is a little bit more stable than Delphi 11 + Update 3. But I am not using either very much due to the (IDE) annoyances when mixing HighDPI monitors and non-HighDPI monitors, so I'm not an authorative source for such a comparison.

I just extended my dzDebugVisualizer package to include a TColor debug visualizer for Delphi 10.2 and Delphi 12. With little change these will probably work for every Delphi Version that supports the neccessary ToolsApi functions, meaning >= Delphi 2010. This is completely different code than I used before, but it still shows the color name(s) and the RGB value rather than the integer value. read on in the blog post

I have now also added a debug visualizer for (multi-line) strings. See the blog post for details.

If by "declare" you mean "add to the uses list": No that I am aware of. In theory you could add the code into an existing unit that's already in the uses clause everywhere. You could create lightweight wrapper functions that get exported from that unit and simply call the original functions in dbugintf, thus basically redirecting the calls. Depending on what you want to do that might work for you.

... and cares enough, to spent some significant amount of money and lately effort on buying and using one.

I forgot to mention, that in the lastest GExperts Beta release for Delphi 12, the configuration tab for the Editor enhancement has been moved to a separate "Editor Enhancement" expert.

When run in the debugger, the IDE sits in the taskbar and I might accidentally bring it into the foreground while I am working on something else in a different IDE instance (or any other program). No big deal but it always interrupts what I am currently doing. But if I am working in a different instance of the IDE I might accidentally change the source code or even worse terminate the debugging without noticing that I am in the wrong IDE instance. This has happened more often than I would like to admit. Any kind of exception will stop the program while running in the debugger, even if there is a handler for it, and bring the IDE to the foreground. I then have to check whether I am interested in it or not. Again, just an annoyance. I could probably turn off "break on exception" for that, but I tend to forget changing this back, in particular if I am working on a different program in a different instance of the same IDE. Sometimes it takes quite a while for the situation I am interested in to occur (we are doing a lot of batch processing on large database files that might run for hours and I might not know what causes the problem so I can't run it on a smaller database), so the program might run over night with nobody there to press the "Run" button if that happens.

As I originally said: It depends on the use case. My programs usually have only the main thread for the UI and possibly one or (very rarely more) worker threads that are independent of each other (no threadpool). In that case it does not matter whether the other threads continue to run or not. An exception won't work because I only use this method when I don't want to run the executable inside the debugger in the first place, so there won't be a dubugger to catch that exception.

There is a package installed in the IDE called "Embarcadero Sample Debugger Visualizers" (package name is: samplevisualizers). Given it's called a sample, I would have expected that the source code is also available, but I can't find it, neither in my Delphi installation(s) nor on Embarcadero's Gitub Sample repository. Any hints?