dummzeuch

Look here: Computer\HKEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS\22.0\Experts

"GNU AFFERO GENERAL PUBLIC LICENSE" According to the abstract this sounds a lot like GPL. But whatever the difference to the GPL might be. This: ... means I can't use it in any of my tools. I'm not going to change the license from MPL to anything GPL like. I was actually thinking about using this to add support for 64 bit executables to the PE Information Expert in GExperts.

I'm unable to find the license for this library. Is it just me, or isn't it stated in the description?

Yesterday, all of a sudden, one of my Delphi programs failed to connect to various WMS servers on the internet. I got the following error message: Error connecting with SSL. error 1409442E:SSL routine:ssl3_read_bytes:tlsv1 alert protocol version Since I was using a recent version of Indy, this should not happen, according to this thread on Delphi Praxis. It turned out that somehow a very old version of the openssl DLLs libeay32.dll and ssleay32.dll had gotten ... read on in the blog post

No, the program should have had these DLLs in its installation directory. And it usually has. Yes, it should. It didn't though. Now it does. The error occurred on my development computer with freshly checked out sources. Normally missing DLLs would have caused an error message which would have reminded me to copy them from a subfolder. Unfortunately there was no error message, just the SSL connection failed. Hm, thinking about it: Maybe the loading code should specify the full path for the DLLs. But that would mean I had to change the Indy sources. I'd rather not do that. Alternatively my program could load the DLLs before calling any Indy code.

993 is the default port for Imap over TLS, so this is probably meant as a feature. (Not that I would have expected this to happen.)

Delphi 11.3 is the 3rd update for Delphi 11 (as opposed to the 10.x versions where each point version was a new release), so there have been updates and each of them fixed some bugs (11.0 was so bad that I didn't even want to spend the time for a GExperts release until 11.1 came out.) I'm not disagreeing that there is a lot of room for improvements, though. I'm not using Delphi 11.3 for production because it isn't stable enough in my environment.

I just made some time for it. I have quite a bit of overtime to work off anyway. #revision 4072

Yes, I kind of knew this (but didn't think of it). But using the internal functions will also help diagnose installations on computers which cannot be accessed directly. A program can present the user with this information or it can be included in an error message or log file.

Thanks! I was about to add these two myself, the next time I find some free time. Having your patch will make that happen a lot faster. I still need some time for this anyway. You are correct. The right way is to use the image lists in Source\Framework\GX_SharedImages, or since Delphi 11, to assign these lists at runtime. See any of the dialogs that have a tool bar on how this is done.

Another option would be to have a procedure like this: procedure TButtons_SetEnabled(const _Buttons: array of TButton; _Value: Boolean); var btn: TButton; begin for btn in _Buttons do btn.Enabled := _Value; end; And call it like this: TButtons_SetEnabled([Button1, Button2, Button3], True); Not much of a typing saver, but not as repetitive. Edit: Just noticed that Uwe already suggested a similar approach.

Does that one also allow pre-filtering the filenames? e.g. If I only want to select from GX_*.pas files, or those matching *.dbf;*.dat ? I already had a similar function for filenames and directories without filtering using SHAutoComplete, but the filtering was important for me. (Short answer: I didn't know about this)

Thanks. Commited as revision #4070. I have made a small change thoug: I prefixed the file name to "- instant grep" like it is shown in e.g. the project manager window so the importantpart (the file name) is visible even if the window is too narrow to display the full title. An unfortunate side effect is that the original position entry now doesn't even show "original position" in the caption. It needs some other way to be distinguished from the other entries.

Yes, I was thinking about that already but didn't find the time to check it out yet.

I'm always interested in possible improvements.

Not a component but a function that adds this functionality to any TEdit: https://blog.dummzeuch.de/2019/04/28/autocompletion-for-tedits-revisited/

Yes.

Yes, it is indeed (as somebody else already mentioned). I originally copied the code from the Editor Bookmarks expert and the plan was to somehow consolidate those copies again. But there, it's also only the current file, so the filename is redundant too. I'll have to think about it some more (and find the time for it).

Hm, yes that could be done. On the other hand, I could move the line number to the left column too, so it occupies the space under the file name which you left empty.

As of revision #4069 the original position is only shown if there are matches. I'm not sure about showing the filename. Yes, it's not really necessary, but since it also shows the line number on the right (which I definitely want to keep), not showing the filename would leave that line mostly blank.

Fixed in revsion #4067 by putting a panel between form and listbox. (No idea why this works, but I tried that because the Grep Results window also had a panel as parent for the listbox. Maybe that's the reason why that panel exists there too.

Hm, that's a really odd problem: I traced through the code and it actually tries to redraw the whole entry, not just the part on the right. But apparently due to clipping only the right hand part actually gets drawn, leaving the part on the left unchanged. (That also applies to the Editor Bookmarks expert. I wonder why the same does not happen in the Grep Results window, which also uses a TListBox in owner draw mode. The difference there is that headers containing the file name and number of matches and the actual lines that match are separate lines, while in Instant Grep and Editor Bookmarks one line contains both, the header and the matches. But the drawing code is nearly identical.

Fixed in revision #4066. Thanks.

It should be a separate menu entry in the GExperts menu. No, unless somebody cares enough to implement support for that and submits a patch.

Then you have been very lucky. Every single GExperts release for the last few years has been flagged as malware. After trying to correct this once or twice by contacting the antivirus publishers I simply gave up and whitelist it for my computers. I don't sign my executables and installers though, maybe that would help.