dummzeuch

On my computer it does not open the file in the IDE but in Notepad++. It simply opens the file with the associated application. And that's the problem: It cannot pass additional parameters for the line number to select, because it does not know which program is called and what to pass for it to jump to the correct line. The only way to do that would be to configure the program to call and which command line it needs. (From within GExperts in the IDE this works, because GExperts knows how to jump to a line number within the IDE.)

Hm, that's odd: if UNICODE is defined: gnugettext.Utf8Decode calls System.Utf8ToWideString which in turn calls System.Utf8Decode (in Delphi 10.3.1) I wonder what caused that Utf8Decode function to be added to gnugettext. Maybe there was a bug in early UNICODE aware Delphis? Or may it's simply because Utf8Decode was marked deprecated at some time. System.UTF8ToUnicodeString contains basically the same code as System.Utf8Decode with the exception that the Temp string is either a _WideStr or a UnicodeString. I'm too tired (I have been banging my had on the table all day to find a solution for a BDE problem under Window 10 😞. It seemed to work at last, when all of a sudden I got a priviliged instruction error 😞 ) to get my head around the implications. For now I see no reason why gnugettext.Utf8Decode should not call System.Utf8TUnicodeString rather than System.Utf8ToWideString, but I'll have to run some tests.

I have asked an admin to remove that post. I have no time now to actually check that race condition you mention.

I think we should not discuss my version in this thread as it is mainly about koskolos' implementation. As I said: I wrote that back when I read about lock free structures but never really tested it thoroughly and lost interest later. It would be too confusing to discuss both in the same thread.

It explicitly says "single reader", so that's a non issue. I agree with the rest of your post though.

A colleague of mine just cleaned his desk and cupboard. And by "cleaned" I don't mean "remove his stuff" but literally remove the dust accrued over several years. Talk about menial tasks...

fixed today in revision #2576

If you get the error “PrivateGXMenuActionManager is not nil upon creation” when starting your IDE, check the entries under HKCU\Software\Embarcadero\BDS\<version>\Expert There are most likely two entries for GExperts. Remove one and the error should go away. These entries come from The installer (GExperts=”path\to\dll”), because it always uses GExperts as the name for the entry. The Expert Manager (GExpertsXxx=”path\to\dll”), because it uses the name of the dll file for the entry. Yes, this is a bug. https://blog.dummzeuch.de/2019/03/01/gexperts-error-privategxmenuactionmanager-is-not-nil-upon-creation/

Fixed today in revision #2576

I want to get a list of interfaces registered in a Delphi 2007 application (with code from within that application) in order to check for possible duplicate GUIDs. There is a solution on GitHub which uses the System.RTTI unit, but unfortunately that unit is not available in Delphi 2007. Is it possible to do without? I also asked on StackOverflow: https://stackoverflow.com/q/54710667/49925

What exactly is an "unattended run" in this context?

The GExpertsRS103 entry is created by the GExperts Expert Manger (because it uses the DLL name as the entry). The GExperts entry is created by the installer.

Odd. I just used the latest GExperts to install it on my development computer and could start Delphi 10.3.1 without any problems. But of course that's different from what you have been doing: Installing GExperts first and then updating Delphi. I remember seeing this error before. If I now just could remember where and what was the cause... Could you please look into the registry under HKCU\Software\Embarcadero\BDS\20.0\Experts whether there are maybe muliple entries for GExperts?

Please note that there are known limitations with GExperts Grep Search on form files. A string will not be found if one of the following conditions is met: A string is split into several lines (in the form file) and the search string spans a line break (Bug #49). A string with special characters (e.g. Umlauts) is stored as 'bla'#nnn'blub' in the form file and the search string spans this special character (Bug #112).

I also uses the compiler Generics, so my guess would be: yes.

Which problem are you trying to solve? We have quite a few rather large executables, but that never posed a problem.

The shortcuts were always supposed to work only when the results window had the focus (some of them conflict with editor shortcuts). Since the switch to the "hamburger" menu, the actions no longer get called. Also, the form's OnKeyXxx events don't get called when the form is docked (key preview is true), so it's not possible to re-route the shortcuts this way. The only way I found was to add global actions, but these would block the editor shortcuts (e.g. F5 to set and delete a breakpoint). So that's not a solution either. In out of ideas for now.

I tried to add yet another expert that uses F5, but unfortunately that disables the F5 key for setting / removing breakpoints, so it's not an option, unless it is turned off and on dynamically whenever the Grep Results window gets the focus. Not my preferred solution.

Hm, that was the switch from a main menu to the "hamburger" menu. I guess that's what causes the problem. I made that change for two reasons: 1. There was a draw problem with the main menu in the latest Delphi version if theming was enabled (which is now the default so the problem would have been there in whatever configuration. 2. The Grep main menu was sometimes stealing the Alt+F etc. shortcuts from the IDE main menu. Now, the Action hotkeys apparently only work if the Grep result window is not docked. (Edit: Now it doesn't even work if it is docked. No idea what changed, definitely not the code.) The edit window seems to take all the hotkeys.

I'm not aware of a change that could cause this. Please file a bug report.

I don't know. Since I currently don't use Rio for anything else but compiling and testing GExperts and a few other tools, it is quite possible that there are problems that I have never seen. Is there any additional information with this error message? E.g. a stack trace? (I known it's unlikely because you would have probably mentioned it, but I'll ask anyway.) I know that if I use the GExperts code formatter (which I do excessively), I often get an AV when closing the (Delphi 2007 and XE2) IDE. I have never been able to find the reason, so it is possible that it isn't the code formatter that causes it but something else entirely. But then of course, it could be that it's not GExperts at all. From your list, I only use CnPack (some very few functions of it) and DDevExtensions, but in Delphi 2007 not in Rio, so that doesn't say much. The others I don't use at all. If you can reproduce the problem, you could try to run the IDE itself in the debugger and you might be able to find out what causes it. That would probably give you a call stack. But beware, there are many exceptions within the IDE itself that you will start to see then, which are not really errors. (But there is one annoying AV in the Welcome Page, which definitely is an error, but gets handled so you normally don't see it.)

For GExperts I usually just let the compiler figure it out. I have a build script that runs a build for all supported Delphi versions (6 to 10.3) and if there is a hint / warning (or error), I check which versions are affected and put ifdefs / if or unit aliases into the project to make them go away. As far as I know there is no official list of which features were introduced when. There are "What's new" entries in the release announcements and there is a StackOverflow "question" which tries to list them, but nothing official and nothing complete.

WTF? Who stores ages as floating point and then uses arrays (which of course use integer indexing) for lookups? And this is a banking application? If this is typical code this whole thing is a rounding error waiting to happen and destroying the whole company. OK, to the actual problem: Add a check for the array bounds to the for loop: if Round(EntryAge) < LowBoundOfArray then raise exception.Create(...) if Round(RetireAge) > HighBoundOfArray then raise exception.Create(...) Where LowBoundOfArray and HighBoundOfArray are the minimum and maximum index values for the array. I don't remember if Delphi 5 already knew the Low(array) and High(array) functions. If it does, use these. My guess would be that a rounding problem causes access to elements ouside the valid array bounds and that causes your error.

Just in case anybody else wants to compile this code. It requires the following uses lists: interface uses Windows, SysUtils, Classes, ToolsAPI, ExtCtrls, StdCtrls, Forms, DesignEditors, ComponentDesigner, DesignIntf; implementation uses Controls, Types;

Where are TSelectionEditor and ISelectionpropertyFilter declared? I expected them in ToolsAPI, but they aren't there. Found them: DesignEditors and DesignIntf