dummzeuch

And other calls to that procedure might actually require an input value: procedure bla(var _Value1: integer; _Value2: integer); begin if _Value2 > 0 then _Value1 := _Value2+1; end; procedure blub; var Value1: integer; begin Value1 := 5; bla(Value1, 3); end; How should the compiler determine whether passing an uninitialized variable to procedure bla is a problem, without analyzing the procedure itself?

I always thought that activation as optional for up to Delphi 7. Now my previously working Delphi 6 installation wants to be registered again. I'm using a valid registration key for Delphi 6 professional. Selecting "I will register at a later time", which always worked, no longer does. WTF? (I blame a Windows 10 "feature" update). Until I have resolved this issue, I can no longer test or debug anything for Delphi 6. Any hints? (Fortunately Delphi 7 still works)

Fixed it. Also added unit tests for this (I could have sworn I already had some. Another faulty thing: My memory.)

I was about to point to my iso8601 unit in dzlib, but when I checked, I found the ToWeekDate method to be possibly faulty in exactly these cases. Should be easy to fix though. https://osdn.net/projects/dzlib-tools/svn/view/dzlib/trunk/src/u_dzIso8601.pas?view=markup&root=dzlib-tools It's ISO 8601 btw. not 8901.

There is also quite a few information about Live Templates in the Delphi Wiki: Delphi Live Templates Editing the template template Live Templates Technical Info (I wrote most of the latter from reverse engineering existing templates and reading blog posts about them years ago, when Live Templates were all the rage.) and also Stefan Glienke's collection of Live Templates

It does not touch any text in strings, only source code.

There is the GExperts Code Proofreader expert which supposedly can correct typos like Heigth to Height etc.. Unfortunately it sometimes does more harm than good by "correcting" words that only look like some words it knows about but are spelled differently (e.g. I tend to use abbreviations for variables of enum types like "tnue: TreeNodeUserEnum" which then gets "corrected" to "True".) It can be set to beep when correcting but that goes on my nerves quickly, so I usually turn it off again.

There are several forms that display metrics. And yes, it's probably possible to disable it by removing some package. No idea which one though. Maybe the package names might give you a clue. The GExperts PE Information expert will show you the classes a package exports, so that might also help to find it. I'm glad my hint helped a bit.

I have just finished making the stand alone GExperts Grep to really be stand alone, that is: It no longer needs the GExperts DLL but contains all the functionality in one executable. It has also been compiled with Delphi 11 Alexandria so it should be per monitor DPI aware. Another feature is the ability to integrate itself into the Windows Explorer popup menu. ... read on in the blog post

https://blog.dummzeuch.de/gexperts-documentation/compiling-gexperts/

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