dummzeuch

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

Look into the thread about the annoucement. Somebody there posted a solution.

I never tried it but it should be possible to have multiple registry branches for each of the package versions and then start the IDE with the appropriate -R switch. Has anybody ever used this (for longer than 10 minutes 😉 ) ?

Unfortunately not even good and reliable descriptions on how to reproduce the bug and even suggestions on how to fix them don't always get it fixed. I sometimes wonder whether they use some random number algorithm to select the bugs to be fixed.

Has anybody looked into the CnWizards source code and knows whether and when it "phones home"? I know about the automatic check for updates and have disabled it, but I still get a noticable dealy when starting up the IDE at the point where CnWizards loads.

Turns out the culprit was not CnWizards but actually the Favorites Files Expert in GExperts. It took forever to read 4096 entries from the registry. And these 4096 entries doubled the next time I called the configuration dialog and doubled again the next time. If any of the CnWizards developers reads this: Sorry for suspecting your code, it was my own.

I recently had a problem with access violations when calling methods of interfaces. The reason turned out to be duplicate GUIDs in the interface declarations. This caused AVs because the wrong methods were called and the parameters passed to them were not of the right type and numbers. Duplicate GUIDs are usually caused by copying existing interfaces and changing them, without also generating a GUID for the copy. (Btw: The Hotkey for generating a new GUID in the Delphi IDE is Ctrl+Shift+G.) So I looked for a way to find all interfaces and their GUIDs in my program. https://blog.dummzeuch.de/2019/02/16/finding-guids-with-gexperts-grep/

No, you don't have a duty. But neither have I. Sorry if that sounded harsh (always remember: English is not my native tongue, some fine points always get lost in translation). It's just that some people (not you!) seem to think they have the right to demand features and waste my time which I want to spend on things that is fun to do. You were the 5th one today who wrote a suggestion (I'm not saying that these are bad suggestions either!) and I got really tired pointing out that there is such a thing as the feature request form on Sourceforge for exactly that. GExperts is an open source project. Everybody has the code and can contribute. But only very few do. I can't even find people who regularly test new features or bug fixes with the Delphi versions I myself don't use.

I said it before (to somebody else on a different topic: Please file a feature request on SourceForge. That way all these are in one place and whenever I find time I can look if something there looks interesting. Anything mentioned only here will most likely be forgotten in no time. (And no: I am not going to write these feature request entries for people who can't be bothered. I prefer spending my time on more interesting things. You get to use GExperts free of charge and profit from my work, so do your duty. - Sorry if this sounds harsh, but my time is limited.)

Talking about more things that (still) don't work: The GExperts Editor-Popup-Menu still does not work if Images are assigned. So I have left the workaround (not assign Images) in place.

Too many of my questions on SO have been closed for me to rely solely on SO any more.

I just tried to download and compile the sources: MultiInstaller_Icon.ico is missng.

I'm not sure that such a tool should support freepascal and Lazarus too. This would: Add a lot more complexity Get the maintainer / developer into unnecessary open vs. closed source discussions Would be a direct "competitor" to an already existing tool which would again cause endless discussions. I'm not a fan of tying it into Github, btw.

I have a list of several thousand points with given X and Y coordinates (cartesian corrdinates in metres, stored as double) and of course additional properties. The list originally is sorted by one of the additional properties. I need to go through this list and for each point find others that are near this point, e.g. have a distance of less than 1 metre. This sounds like it should be a common problem and there should be an existing solution, but my Google skills have failed me. My approach would be: 1. Create two sorted lists, ListX sorted by X, ListY sorted by Y. 2. For each point find the points in ListX and ListY that are near the point's coordinates (example: Less than 1 metre in that direction.) 3. Take those points that are in both results and check their actual distance to my given point.

Rather than hooking an event, which might already be hooked, you can create a custom TComponent descendant and set the main window as its parent. The main window will then destroy that component before it gets freed and you can intercept that to do whatever you need. Regarding chaining events, see here for my suggestion to play fair with other plugins.