dummzeuch

GExperts is always compiled with the latest update of any of the supported Delphi versions. That unfortunately means that it may not work if the IDE hasn’t been updated to the latest version. E.g. The latest GExperts release will not work with Delphi 10.2, but only with Delphi 10.2.3, the latest update to Delphi 10.2. This is due to changes in the runtime packages that are not always backward compatible. Until a few years ago, this was no problem because when you bought Delphi you were automatically entitled to receive all updates for this version. E.g. if you bought Delphi 2007 you could download all updates for it and GExperts would simply work for you. This changed when Embarcadero tried to force all their customers to buy a maintenance subscription. Read on in the blog post.

That doesn't sound like up to date documentation.

Format is very flexible but unfortunately there is no compile time checking for the (or has it been added in newer Delphi versions?). Unfortunately it's also difficult to debug (from user error reports) since you don't see the format string in the error message. That's why I always hook this function and add the format string to the error message. If anybody is interested, I can post that unit here.

The second syntax is meant to be used with variables rather than constants.

I always put libraries into their own Subversion repository and add that as an "external" to the project repositories. This results in the libraries to be checked out into a subdirectory of the project sources. I never add the library sources to any global search paths in the IDE, but only to the respective search paths of the project. And there never as absolute but only relative paths. E.g. if my project goes to D :\source\myproject the project sources (including the .dpr file) go to the subdirectory src D :\source\myproject\src the libraries go to the subdirectory libs D:\sources\myproject\libs\lib1 The search path then includes ..\libs\lib1\source I think I blogged about this a long time ago. I'll add the link if I can find it. Found it: http://www.dummzeuch.de/delphi/subversion/english.html (Took me longer because it was in my old blog.)

If I remember correctly (from Google+ times), sharedr is written in Delphi. And If you want a suggestion, what to write: A countdown timer (tea timer) for the lock screen. Meaning one that does not require me to unlock the phone to start a countdown. Currently I'm using Ingress Timer but that one requires me to unlock the phone. I'd be willing to pay 5 Euros for such an app. Not sure if anybody else would, though.

getitcmd -c=onlinemode (I'm not sure about the parameters, use the --help option to look out it up.)

Google can't find files that aren't referenced anywhere (it doesn't work with magic), so if the links are only available from pages that cannot be indexed, it can't find the links, regardless whether the files themselves are available without a logon. There are several files on my homepage that you won't find in Google. But everybody I provide with the link can download them without login. It's not highly secure, as it would be possible to guess the urls or to brute force them but it's secure enough for my purpose. Maybe Embarcadero thinks similar? It's convenient to be able to use a download link on a different computer than the one used to login. I usually download the ISOs for new Delphi releases with wget from a Linux server rather than having to keep my computer running until the download finishes.

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.