dummzeuch

Worked for me too now. Thanks.

Yes, in particular it's the 24 keys variant I am accessing (directly, not via keyboard or mouse emulation): https://xkeys.com/xk24.html

OK, I have now translated the C headers to Delphi. Works fine, but the API has some quirks.

When I decide to use code generated controls, I usually start with visually designed controls anyway and later on convert these controls to code with the GExperts Components to code expert. But mostly I simply go with the visually designed forms, even if it mostly duplicates some form. Unless there is a lot of duplicated code I don't care.

Does the Community Edition even include these subscription only updates?

If I remember correctly, this topic has been discussed before and the admins have explained their reasons for these restrictions. Try searching the forum.

Please file a bug report.

I have just updated the Delphi Custom Container Pack sources to support Delphi 10.3 Rio. This time it required than creating the packages for the new version and adding the latest version of the Delphiversions.inc file. When loading the designtime package an EAssertionFailed exception ... https://blog.dummzeuch.de/2018/12/29/delphi-custom-container-pack-updated-for-delphi-10-3-rio/

With the price for Professional rising the way it does, it feels like I'm on enterprise already. I was pleasantly surprised I got the mobile add-on without paying an arm and a leg though.

Hooking events in the Delphi IDE is dangerous, as you never know whether there already is another plugin that uses the same event. I tried to describe a way to make that process a little bit safer and blogged about it: https://blog.dummzeuch.de/2016/03/28/safe-event-hooking-for-delphi-ide-plugins-revisited/ But it's not just other plugins you must be wary about. New versions of the IDE might also start using previously unused events. E.g. Delphi 10.3 is now using the previously unused Screen.OnFormChanged event, but only within the Options dialog. This broke some of the GExperts enhancements to this dialog and those dialogs opened from there, in particular those for the path edit dialog.

My gripe is not with whether it looks pretty or not, but whether it's usable at all. To get back to the original post's topic: A visual clue that a control is read only, would be nice. But Windows 8 and later 10 ruined that (and that's far from the end of the visual catastrophe these versions introduced). Or take web sites: It used to be that links were easily recognizable with blue text color and underlined. The first thing that disappeared was the "ugly" blue color. Then web designers also removed the underline. Nowadays you only know for sure that something is a link when you click on it. Or one example from non software related design failure: The controls for a faucet (Deutsch: Armaturen) used to show with a blue or red dot that was easily visible whether you turn on cold or hot water. Today these dots are still there (not sure whether that's required by law), if you either know where to look or crane your neck to find them. Apparently somebody decided that they spoil the look of the thing, so they are now hiding them. I'd like to know how many people accidentally get burned because of this.

But would that not simply delay the problem? Since he said that the code must access the form, the callback method must still check whether the form still exists when it wants to write to the OLE container on the form.

Do you actually need the form in the event handler? If not, you could pass a plain procedure pointer instead.

I wrote about autocompletion for TEdits before here and here. Back then I was using the SHAutoComplete API function in the Shlwapi.dll because I am a lazy basterd™. That hasn’t changed really but I also love fiddling with stuff, so some years ago, I actually added directory and general string completion to dzlib (and apparently didn’t blog about it), this time using the IAutoComplete2 interface as described in this answer on StackOverflow, which I mentioned before. Today I revisited that code and and added file and directory completion to it, in a way that also allows filtering the files with a given file mask. So the user can easily enter directories and eventually select a file: Read on in the blog post ... https://blog.dummzeuch.de/2019/04/28/autocompletion-for-tedits-revisited/

Hello @jbg I was wondering why I could no longer debug GExperts. Every time the secondary IDE closed or even if it was killed using the Run -> Program reset action, the primary IDE hung. I disabled the various extensions I have installed in the IDE (first of all GExperts, I always mistrust my own tools first) and it turned out that the IDE Fixpack 6.4.2 was the culprit. After I disabled it, everything went back to "normal". So I tried to find out whether disabling some of the options made any difference: * This is the default settings which causes the problem * This doesn't: * This causes the problem: * and again, this doesn't: So it seems to be the option "Install Compiler Speed Pack" which is the culprit. Unchecking it solves the problem. To reproduce the problem: * Start Delphi * Create a new 32 bit DLL project: File -> New -> Other -> Dynamic Library * Set the host application to the Delphi IDE: Run -> Parameters, set Host application to the full path of the bds.exe * Save the project * Compile and run it in the debugger * Let the secondary IDE instance start and simply exit it with File -> Exit * Wait for the secondary IDE to terminate. * Die of old age while waiting. It won't terminate. This is with Delphi 10.3.1 "professional with mobile" If I can be of any assistance trying to track down this problem, please let me know. twm

Windows 8.1 on both computers, at home (where it happens) and at work (were it doesn't).

Apparently this program is not very important for the company, so maybe it should just be retired instead of being replaced. Or is somebody maybe having the wrong priorities here?

I have now also tried it with my installation at work. Can't reproduce it there either. And there I thought that for once I had a nicely reprodicible error... 😞

Hm, that's odd. Happens for me every single time. Could anybody else please try? The steps should be easy to follow.

And then there are the small tools, that are (planned to be) used only for a special problem and then probably never again. It's OK, if you tightly couple UI and business logic if it makes writing them faster (true RAD). Unfortunately some of these tend to live longer than expected and functionality tends to be added later, which would require a redesign. But of course that never happens, because "it works as it is" and the new functionality is "just a very simple addition".

No idea, Cortana is one of the first things I disable when I install Windows. As far as I'm concerned, Cortana is the devilish twin of Clippy.

Does anybody know whether GExperts ever included a "Select Components" expert? It looks like this: or like this in expanded mode: I just found that there is source code for such an expert in source\experts\GX_SelectComonents but it has not been added to the project(s), so it does not show up in the experts list. It seems that it was originally written by Rossen Assenov who put in on CodeCentral with the following comment: The source was already part of the GExperts sources when they were moved to the SVN repository on SourceForge in 2007 but they were not part of the projects even then (so it wasn't me who accidentally deleted them). It also seems to work, even though it lacks the flexibility of its CnPack counterpart "Component Selector":

Can anybody else reproduce this in 10.3.1 ? If a large project is open, selecting Project -> Add to Repository the first time causes several seconds of flicker of the "Palette" tab and various other parts of the IDE until finally the dialog gets displayed. Even then the dialog's title keeps on flickering for a while. This does not happen with small projects e.g. the default VCL project. steps: Start the IDE (you must do that, it only happens the first time after a new start) Open a large project (I used GExperts) Select Project -> Add to Repository -> The Palette tab is flickering for several seconds until finally the "Add to Repository" dialog gets displayed. Reported here: https://quality.embarcadero.com/browse/RSP-24338

Revolutionary idea: If Embarcadero wanted to invest a large amount of dev effort (which translates mostly but not only into spending money) into Delphi, they could put that effort into fixing bugs in the existing IDE. Since the number of bugs seems to be growing rather than dwindling, what does that tell you about their priorities?

I have now disabled that functionality for Delphi 10.3.1.