dummzeuch

And here is a doAdvancedDrawItem method that works with older Delphi versions (tested with Delphi 2007) procedure THeaderMenuItem.DoAdvancedDrawItem(Sender: TObject; ACanvas: TCanvas; ARect: TRect; State: TOwnerDrawState); begin {$IF declared(TStyleManager)} ACanvas.Brush.Color := TStyleManager.ActiveStyle.GetStyleColor(scPanelDisabled); ACanvas.Font.Color := TStyleManager.ActiveStyle.GetStyleFontColor(sfWindowTextNormal); {$ELSE} ACanvas.Brush.Color := clDkGray; ACanvas.Font.Color := clWhite; {$IFEND} ACanvas.Font.Style := [fsBold]; ACanvas.FillRect(ARect); ACanvas.TextRect(ARect, ARect.Left + 3, ARect.Top + 3, StripHotkey(Caption)); end; To get it to compile with Delphi 2007, just remove the unit namespaces from the uses list. Adjust the colors to your liking.

Just in case anybody is interested, here are two overloaded constructors that make it much more convenient to insert such group headers into a menu: interface type THeaderMenuItem = class(TMenuItem) public // default constructor as above constructor Create(AOwner: TComponent); overload; override; constructor Create(_ParentMenu: TMenuItem; _Idx: Integer; const _Caption: string); reintroduce; overload; constructor Create(_ParentMenu: TMenuItem; _InsertBefore: TMenuItem; const _Caption: string); reintroduce; overload; end; implementation constructor THeaderMenuItem.Create(_ParentMenu: TMenuItem; _Idx: Integer; const _Caption: string); begin Create(_ParentMenu); Caption := _Caption; _ParentMenu.Insert(_Idx, Self); end; constructor THeaderMenuItem.Create(_ParentMenu, _InsertBefore: TMenuItem; const _Caption: string); var Idx: Integer; begin Idx := _ParentMenu.IndexOf(_InsertBefore); Create(_ParentMenu, Idx, _Caption); end; And, as I just found out: Don't forget to set the Style property of the menu to msOwnerDraw set the OwnerDraw property of the menu to True!

I'll accept patches for that. 😉

There are three plugins with that name. I linked them all in my blog post. https://blog.dummzeuch.de/delphi-ide-explorer-expert/

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.