dummzeuch

The the first one is probably because key press is declared with an AnsiChar parameter. The others are warnings. Everything boils down to string in Delphi 10 being WideString and the Char being WideChar, while in Delphi 7 these are AnsiString and AnsiChar respectively. This changed between Delphi 2007 and 2009.

In Delphi 11 I see several oddities in the path editor dialog (e.g. Library Path or Unit Search Path: 1. The "Tasks" and "Replace" buttons are in front of the edit control. That happens immediately when it's being opened: 2. The buttons with icons on them for moving entries and for selecting a folder lose these icons as soon as I move the dialog from one monitor (scaling = 125%) to the other (scaling = 100%) 3. This only happens when the dialog is opened on the monitor with scaling = 100%: The OK, Cancel and Help buttons are no longer right aligned but are somewhere on the left and move even further to the left when I then move it to the other monitor. Does anybody else see these too? Or is that just me again with my peculiar setup (Main monitor = 24" on the right with 100% scaling, secondary monitor = 32" on the left with >100% scaling, with the IDE on the secondary monitor)? I haven't filed a bug report yet, because I first wanted to ask this question to write a better report.

Looking at it in the Delphi IDE explorer revealed the cause for problem 1: The Add and Delete buttons are placed on the pnMain panel, while the Replace and Tasks buttons are placed directly on the form. How can a rookie mistake like this not be spotted during tests?

Actually that should already happen. If it doesn't, that's a bug.

Thanks for the hint, but I didn't see any performance improvement when enabling it. It's possible that enabling is not enough though, but I have no idea what else to try.

Maybe somebody who experiences this problem could use an IDE Explorer plug-in to find out what kind of form this is? That could give you a clue about the cause and how to avoid it. (I never saw that error, but I rarely use this IDE version.)

By the look of it there are two factors: 1. Every rescaling of a control seems to cause a redraw of the whole form. There should be a way to block redraws until scaling has finished. I tried a few tricks, but none worked so far or had side effects that I didn't like either. 2. Moving a form between monitors with different scale factors often seems to trigger the rescaling multiple times. (That might be a peculiarity of my test program though.) In particular the IDE takes several seconds to rescale. That's really annoying, and I'm glad that I currently don't have to use it for my day work. Btw.: How well does the scaling work with fmx programs?

I had that effect several times now (with the /highdpi:unaware IDE): Run a program in debug mode At a breakpoint open the "Eval/Modify" dialog (Ctrl+F7) and type the name of a TComboBox Click "Inspect" to open the "Debug Inspector" window After a while looking round the properties the IDE hangs using 100% on one core. Has anybody else seen this?

No, by having a destructor that can handle partly constructed objects.

I'd tackle this conversion in two steps: Convert from Delphi 7 to whatever newer Delphi version you fancy and keep the BDE. That UNICODE string conversion is less problematic than many people (including me until recently) think. Only very few places need to be changed at all. Unless you were (ab)using strings for storing binary data, that might cause more work. Once that's done, convert from BDE to whatever database format/access component. I haven't got much experience with this part. We have moved from the BDE to tdbf (mind the license though!) for working with Dbase tables.

I never understood the benefit of writing the ExplicitLeft / Top / Width / Height properties for TControl and descendants, which were added in Delphi 2007, to the dfm files. They store the control’s position and size before its Align property was set to something like alClient or alRight, so they can be restored later. That’s useful if you change these by accident or double click on the Align property to go through the possible values, but as soon as you save the form, you don’t really need them any more. Even worse, they seem to change often with no apparent reason and therefore clutter a dfm file’s diff with changes that nobody is interested in. read on in the blog post

That should actually go to @Achim Kalwa who provided the code I integrated.

Isn't there a configuration option, how many recent files the IDE remembers and shows in this menu? Having to remove them manually can't really be the fix.

While I agree in principle, an open source project without somebody actually maintaining it, is pretty much useless. And I can tell you from experience that it takes a lot of time and effort. On the other hand, a closed source plugin without somebody maintaining it, is totally useless once a new Delphi version is released.

There are still some bugs with generics in the code formatter. You might get lucky and find that this particular bug has been fixed already in the current GExperts source code. To test this, follow the instructions to build your own DLL and replace the one that came with the installer. If it isn't, please file a bug report, make sure to include some minimal testing code. You can even try to fix the problem yourself, you have got the source code after all.

A mess like this is the reason why I am usually not thrilled when Embarcadero buys some tool or some components/library and takes over maintenance.

This usually happens, if the code in the packages (used in the IDE) and the code in your program is out of sync. Did you maybe update these components and forgot to adapt the search path in your project?

Venting here might provide some release of frustration (I know, I've done that too), but it won't change anything. Try to provide god bug reports on the Embarcadero Quality Portal.

Not quite: You can write Windows device drivers with C. I doubt very much that this is possible with any Pascal based development tool. Also, while basically all APIs and SDKs provide bindings for C / C++, many don't provide them for Pascal / Delphi. I had to translate lots of C header files to Pascal for e.g. accessing API for cameras or laser sensors.

That's why I'd recommend to buy / switch to a Network Named User license(*1). Then you run your own license server and will not have to beg for new activations. (*1: For companies it might also be an option to buy Network Concurrent User licenses that are not tied to a specific user (even though it is easily possible to change the user of a Network Named User license). Code Partners described the various types of license available in a blog post.) (edit: Uwe was faster....)

Aren't those patches only available for those who have/had an active subscription at the time the patch is/was released? I seem to remember reading that somewhere.

I just checked our Linux servers for Java programs using Log4J. One that was found, was the Embarcadero License Server. It uses log4j-1.2.15.jar: /opt/Embarcadero/ELC5.33/ReportingEngine/lib/log4j-1.2.15.jar. Now the question is: Is this version affected? According to various sources, the affected versions are 2.0-beta9 to 2.14.1, so that would mean the version used in ELC is not affected because it is so ancient. Unfortunately there is another view on this: It's after August 2015, so at least the Apache Foundation has not checked the 1.x versions for this vulnerability. I have no idea when the vulnerable functionality was introduced. It might have been during development of Log4J2 so version 1.x would not be affected. Does anybody else have information about this? Did you maybe already hear from Embarcadero? @Moderators: Feel free to move this post to a different section if you think it does not belong here.

According this posting, Log4J 1.x might also be vulnerable but the risk is much lower. Also, of course, you should be safe as long as you don't expose the ELC to the Internet. (And who in their right mind would do that?)

Maybe the "Unread Topics" button is what you are looking for. That's my main entry point into DP. The link is: https://en.delphipraxis.net/discover/[your user id here]/#

Insert a "being" at the appropriate position. Hm, worked for me the two times I tested it. Have you selected the option "Use current editor identifier as the default search string"? It must be enabled for this to work.