Mahdi Safsafi has proposed a fix for the bug in the GExperts Filter Exceptions expert, which occurs when developing for non Windows targets (first reported on Embarcadero’s quality portal ). I have implemented this fix and it doesn’t have any adverse effects on for Windows targets. But neither he nor I can test it for non Windows targets since we don’t develop for these. That means we need testers. If you want to help, please post a comment on the bug report on SourceForge.
I have received a few reports about bugs in GExperts in Delphi 10.4.1 that do not occur in Delphi 10.4. Here is a GExperts DLL that was compiled with Delphi 10.4.1. Maybe it will solve some of theses problems.
Simply extract the DLL and put it into the GExperts installation directory, replacing the original one.
Let me know on Delphi Praxis whether this fixes the problems.
The GExperts PE Information tool just got a small improvement:
The Exports list can now be sorted by clicking on the column header and filtered on the export name by simply typing text.
The Escape key resets the filter.
I my last GExperts related blog post I wrote about the new “Close Exception Notification” expert which I just had added to GExperts. It was a hack that hooked the Exception Notification dialog.
This spawned a discussion in the international Delphi Praxis forum and resulted in a rewrite of the expert. It’s now called “Filter Exception” expert and instead of hooking the dialog it directly hooks into the code that shows this dialog. Thus it prevents the dialog from being shown for filtered exceptions.
In that same discussion Der schöne Günther suggested to add a project scope to the filtering. I have implemented that too.
So now the expert can filter on:
- Project name, which is a regular expression.
- Exception class
- Exception message, which again is a regular expression
I have added all those exceptions that the Delphi IDE raises on every startup to my filter. It filters on the Project = “GExperts.*”, the exception classes and the messages it shows.
That means it will no longer annoy me with them while I am debugging GExperts but will still show them for other projects.
The filter details look like this:
It’s also possible to add a filter for the current debug session only, which means that it will be deleted automatically once the debug session ends.
Unfortunately hooking of the code is only available for Delphi 2005 and later. Older versions still have got to hook the Exception Notification dialog.
If you want to test this new functionality, you’ll have to compile your own dll. Try it, it’s not rocket science!
If you want to discuss this article, you can do so in the corresponding post in the international Delphi Praxis forum.
I got into programming because I am lazy, I’d rather have the computer do the boring work than doing it myself. So it’s no wonder that I always liked Delphi and GExperts because both support my laziness.
Today I added yet another feature to save me a key stroke or mouse click: The “Close Exception Notification” expert.
You probably have encountered those libraries that always raise the same exception class on errors, or even worse, raise the generic Exception class instead of bothering to declare their own. And if I should guess, you have probably been guilty of doing that yourself (as I definitely have).
Why is that a problem, you ask?
Because you can’t easily ignore these exceptions during debugging. You always get this “Debugger Exception Notification” dialog, have to read it and decide whether you want to break and look at the code or ignore the exception:
There is this nice option to “Ignore this exception type”, but unfortunately ignoring the exception class “Exception” is rarely an option.
The same problem occurs with other rather generic exceptions like EFOpenError which you can’t really simply ignore but need to check for the file name.
So, what we need is a more finely grained filter based on the message.
Enter the new “Close Exception Notification” expert. It adds a “GExperts” button (I need a better caption) to the dialog above which lets you add filters for Exceptions based on class name and message. And since it was more convenient for me (more laziness), the message filter is a regular expression.
This button will call a configuration dialog which allows you to configure how to handle the current exception.
This dialog is mostly pre-filled if opened through the button on the “Debugger Exception Notification” dialog.
You first enter (there will be some kind of recently used list in the future) the exception class name and then a regular expression for the message. In the simplest case this can be the whole message (but beware of characters which have a special meaning in regular expressions, like ‘.’, ‘*’, ‘?’ or ‘\’). There is an additional input field which you can use to test whether the regex matches the message. When you are satisfied with your newly created rule, select the action to take automatically and press OK. The dialog will close and the action will be executed for the first time, e.g. the Ignore button will automatically be pressed.
The “Close Exception Notification” expert does not have a menu entry. But there is a configuration dialog which gives you a list of currently configured filters.
Unfortunately since this expert cannot directly modify the IDE code and I am not aware of any Open Tools API access to the exception notification, it has to hack the dialog. This results in the dialog being displayed for a short time before the expert “presses” the button for you. This is certainly not ideal but still better than not having it.
There is no GExperts release with this new functionality yet, so in order to get it, you will have to compile your own DLL.
There they are, the promised GExperts 1.3.16 installers for older Delphi versions.
I hope this time the installers won’t be wrongly detected as malware by virus scanners. Sorry about that.
The new version is available for download on the GExperts download page.
Today I downloaded and installed the latest and greatest Delphi 10.4. The first thing to do, was of course compile GExperts for it.
Thanks to Achim Kalwa I already had a working project and he also made all other changes necessary to make it compile. So basically I loaded the project and pressed Compile.
A few tests have shown no problems, but I am sure there will be some. On the other hand I don’t want to be the one to find them all. That’s what users are for, aren’t they? 😉
For those still using older Delphi versions, there will also be a GExperts 1.3.16 release shortly. Watch this space.
Unfortunately sometimes an include file itself sometimes includes other files (e.g. jclNN.inc in the JEDI Code Library includes jedi.inc) which will usually add additional symbols which are then available for conditional compilation. But the IFDEF expert only listed symbols from the original include file.
This has irked me for a long time, so today I changed this: Every include file that is included via an include file (and recursively via these include files) is now listed in the IFDEF expert:
In this example dzlib.inc itself includes dzlibjedi.inc which is simply a copy of jedi.inc. (I don’t want to include jedi.inc directly in order to not have a stale file laying around which might break compilation of other libraries.) The expert lists this file as if it had been included in the unit source code in addition to dzlib.inc.
And, since I seem to have forgotten to blog about it: The expert also searches for available include files in the search path and allows you to add them:
Just select the file from the menu and select the symbol you want to use. The required include directive will automatically be added to the interface section of the current unit.
Guess what? It’s brilliant. It does exactly what I always wanted to write (and never came around doing) for the Unit Tests of the GExperts Code Formatter.
Those tests basically consist of a set of input files in one directory and for each of the tested configurations another set of files with the expected output. It always irked me that I actually had to write some code every time I added a new test instead of simply adding another bunch of files.
Today I changed those tests to use Uwe’s unit (with a few modifications to make it compatible to Delphi 2007). And I found that there were quite a few files which didn’t even get tested at all, because I forgot to add the code.
I’m happy to report that even with these additional tests, the number of failed tests did not increase.
As I add new functionality to GExperts the menu it displays grows larger and larger. On small monitors (there are still computers with e.g. 1024×600 pixels screen size in use, usually not with the latest Delphi version though) this means that the menu has to be broken into chunks, each with a “more” entry at the end to display the next chunk.
While this has been implemented for years (decades actually) it didn’t work very well. For Delphi 6 the code was completely broken (I might have been the culprit myself) it still had some bugs with all later versions.
No more. Today I fixed those bugs and tested it with screens as small as 640×480 pixels.
Also, when moving the GExperts menu into the Tools menu, there was a problem that the maximum number of entries for a chunk was not calculated correctly which would mean that the “more” entry could end up outside the visible area. This has also been fixed.
Unfortunately this does not solve the underlying problem: The menu keeps growing. There are now a maximum of 45 + 3 Entries in that menu. The way that menu is created on demand, depending on which experts are enabled or not, does not lend itself to a sensible menu structure.
I have added a “Category” property to each expert, which so far is neither filled nor used anywhere. I plan to create only one entry per Category in the GExperts menu with sub menus for each category. Maybe I will even make those categories configurable. But that’s for another day.