dummzeuch

No, not yet. But you can always get the sources, apply the fix proposed by @merijnb and compile your own DLL.

As @Uwe Raabe already suggested: The commandline compiler dcc can compile single pas files to a dcu. So you could use a batch file that only compiles the pas files and creates dcus using the command line compiler. You only need to figure out the parameters once and generate that batch file using e.g. the map file of your project(s). No idea whether that would actually speed up the process though.

These don't, but the girls do. "Frauenpower" as we say in Denglish. (Hm, not sure whether this is sexist. If it is: Sorry ladies this is meant to be a joke.)

So the solution is simple: Let's invent a time machine, go back to 1968 and kill N. Wirth. Problem solved. Or, a bit less blood thirsty: Get him involved with a girl that keeps him from inventing Pascal. 😉

Ouch. I guess this shows that I'm not used to inline variables.

On the positive side: This way Delphi developers learn about pointers and how to use them correctly. 😉 type PFoo = ^TFoo; TFoo = record // Lots of stuff here end; PBar = ^TBar; TBar = record Foo: array of TFoo; // Even more stuff end;  TFooBar = array of TBar; var FooBar: TFooBar; begin with FooBar[i].Foo[j] do WhatEver := 42; var Foo := @(FooBar[i].Foo[j]); Foo.WhatEver := 42; // Nope. end; (Now, It would be really embarrassing if I got this wrong. 😉 ) I'm always unsure whether I need the parenthesis in this: var Foo := @(FooBar[i].Foo[j]);

I got a bug report for GExperts and Delphi 10.4 that’s really curious: When a secondary editor window is open in the IDE and the FMX form designer is active, trying to insert a component from the clipboard into the form inserts the textual description of that component into the editor windows instead. I could immediately reproduce this but finding the culprit took quite a bit longer. (Read on in the blog post) TLDR: The workaround is to disable the "Goto Previous / Next Modification" editor experts.

It seems that disabling two editor experts (and restarting the IDE) fixes this problem: Goto Previous Modification Goto Next Modification No idea yet, what causes it. Could you please confirm this @Diego Simonini ? I guess it's the way these experts add themselves to the editor popup menu. This probably makes Ctrl+V always call the editor popup menu's Paste entry (or the associated action) even if the editor window does not have the focus.

No, it's actually pretty easy. Unfortunately I know of no existing way to call an external tool and put its output into such a list view. But it might be worth writing one.

I'd use GExperts Grep, of course. But the question was: I would prefer the IDE search over more powerful external tools if it can somehow still fit the bill for the convenience of easily navigating to the found lines.

Because many of us like to work in the IDE and prefer it to use tools that integrate with it. Of course one could add a commandline grep to the IDE's tools menu to automatically run it on the current unit, but even that would not result in a clickable list of possible offending lines.

COVID-19 got us all down a bit and even with the vaccines theoretically available now, the light at the end of the tunnel seems very far away. My own turn for a jab will probably not come before fall 2021, so I can only hope that summer will reduce the infection rates as much as it did last year, but the new mutants that spread around the world definitely aren’t good news. Maybe I can lighten up your mood a bit with a new GExperts release. There are a few bug fixes and an also a few new features in the new version, but nothing really exciting. read on in the blog post.

Get well and I hope you won't get any of the Long Covid symptoms I read about. I plan to get vaccinated the first chance I get. Unfortunately that will likely not be before fall, given the current availability of the vaccines here in Germany, NRW. Too old to not be afraid, too young to get priority and no important job either. OTOH I can work from home 99.9% so it's OK.

Workaround for the moment: Use the context menu entry "Edit -> Paste" of the form designer.

Interesting, I can reproduce it. Happens with GExperts installed, doesn't happen without. I also tried to disable the automatic popup for the Rename Components expert dialog, didn't help. I haven't tried to disable that expert altogether yet. Please file a bug report on Sourceforge for that.

Why should programmers care about building times? https://xkcd.com/303/

@osterhaegar I got the time until the list is shown and filtered down further. Consistently to about a second with my largest project (>5000 units, 140000 identifiers) on Delphi 2007. Reading the cache files for the units takes the longest time now. They are on an SSD, so there isn't much I can do unless I add them all to one project specific cache file, which I'm considering. With Unicode Delphis it's significantly worse though, there the sorting part takes more than half a second rather than 100 milliseconds. Again having a pre-sorted project specific cache file would help. One unexpected cause for the delay was that I had set the timer, that checks whether the unit parser thread has finished, to 500 milliseconds. Reducing this to 50 milliseconds shaved off another 400 milliseconds from the total time. (Yes, I timed it. I know that I claimed it took 1 second on my machine even before Osterhaegar's an my optimizations. That was wrong, it was more like 2.5 seconds for the above mentioned largest project. Smaller projects (like GExperts itself) took about 1.5 seconds.) But at least I know now where the 3 seconds that Stefan experienced came from.

Opps, I missed the part about the standard defines. Sorry.

Since I just stumbled over the following declaration in Toolsapi.pas: type TGetSrcLinesFunc = function (LineNum: Integer; ClientArg: Pointer): Integer {$IFDEF LINUX} cdecl; {$ENDIF} {$IFDEF MSWINDOWS} pascal; {$ENDIF} IOTAProcess90 = interface(IOTAProcess70) ['{BEBD67CA-F6FC-44A7-ACBF-E314DB085827}'] { Indicates if process properties can be set on this process (via the thread view) } function CanSetProperties: Boolean; { Called when the user asks to set properties for this process (via the thread view) } procedure SetProperties; Which breaks the GExperts unit exports parser because the code is invalid, if neither LINUX nor MSWINDOWS is declared, but I just tested your tool and it works: I wonder how your tool handles this. Do you add one of these symbols to the parser? If yes: It only has one index independently of the platform, so how does it decide which one to use while creating that index?

We have lots of legacy code that still uses "with" and I'm hesitant to touch this code because of this (Guess what's also missing? Unit tests. I add them when I find the time, but progress is slow.) A tool that reliably removes "with" statements would be awesome. Unfortunately it's also far from trivial.

Yes. Hm, thinking about this, It should better be raise [a-z]*\( Because there might be exception names that do not start with an "e". And of course the match should be case insensitive.

Greping for “raise e[a-z]*(” and ” e[a-z]*\.Create\(” will find bugs with (not) raising exceptions.

There aren't any options with QPC. It just returns a 64 bit int. Which TStopwatch passes on to you. And the performance counter frequency is also available. There are alternative options to using TStopWatch, that's what I meant, e.g. using GetSystemTimeAsFileTime, GetTickCount, GetTickCount64. I'm not suggesting to use these for high precision timing in general, they are just options for some particular cases, e.g. if you don't want an Int64 but an Int32 for whatever reason.

Yes, I was wondering the same. There are only two reasons not to use TStopWatch: You are using a Delphi version that didn't have that yet (e.g. Delphi 2007) You want to play with various options.

None of these sources claim that QPC used together with QPF was imprecise. Just that they are based on different time sources, depending on hardware and operating system and therefore the resolution and overhead for the calls vary. As far as I understand it, there is a guaranteed resolution of at least 1 microsecond for all those cases. There are other factors that affect timing much more than these, e.g. what else is running in parallel and whether there are context switches. Also, they cannot be relied on for high precision timestamps that must be consistent between multiple CPUs, but that has nothing to do with performance measurements.