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.
Delphi, GExpertsComments Off on New Filter Exceptions expert in GExperts
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.
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.
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.
Delphi, GExpertsComments Off on The annoying problem of the growing GExperts menu
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.